php-src/sapi/cgi/config.m4

85 lines
2.3 KiB
Plaintext
Raw Normal View History

Generalized server-API build process on UNIX. Each SAPI implementation now has its own directory under sapi/, just like extensions have theirs under ext/. To make the final targets appear in the main dir, the top-level Makefile includes sapi/NN/Makefile.inc from the selected sapi backend. This is a plan Makefile stub without any autoconf substitutions. Each SAPI backend also has its own config.m4 like extensions (read at the end of diversion 2) and config.h.stub files. Each SAPI backend has to contain: config.m4: just like for extensions, this file contains autoconf/automake directives that end up in the configure script. The only difference is that the sapi config.m4 files are read in diversion (output block) 2 instead of 3. The sapi config.m4 files should set two variables: PHP_SAPI (which sapi backend to choose) and SAPI_TARGET (the name of the resulting library or program, previously BINNAME). If they are not specified, they will default to "cgi" and "php", respectively. Makefile.inc: has to exist, has to define "INSTALL_IT" to the command used to install the final target (or ":" for no operation). It also has to define a plain Makefile rule (without autoconf substitutions) to build $(SAPI_TARGET) Makefile.am: just what you think. Make sure your target is called "libphpsapi_NNN.a", where NNN is the value of PHP_SAPI. Some testing and fixing probably remains. To make everything hang together, I've done some ugly tricks that I can imagine causing some problems. I've built and run the CGI version and built the Apache DSO.
1999-09-27 16:34:28 +00:00
if test "$PHP_SAPI" = "cgi"; then
Generalized server-API build process on UNIX. Each SAPI implementation now has its own directory under sapi/, just like extensions have theirs under ext/. To make the final targets appear in the main dir, the top-level Makefile includes sapi/NN/Makefile.inc from the selected sapi backend. This is a plan Makefile stub without any autoconf substitutions. Each SAPI backend also has its own config.m4 like extensions (read at the end of diversion 2) and config.h.stub files. Each SAPI backend has to contain: config.m4: just like for extensions, this file contains autoconf/automake directives that end up in the configure script. The only difference is that the sapi config.m4 files are read in diversion (output block) 2 instead of 3. The sapi config.m4 files should set two variables: PHP_SAPI (which sapi backend to choose) and SAPI_TARGET (the name of the resulting library or program, previously BINNAME). If they are not specified, they will default to "cgi" and "php", respectively. Makefile.inc: has to exist, has to define "INSTALL_IT" to the command used to install the final target (or ":" for no operation). It also has to define a plain Makefile rule (without autoconf substitutions) to build $(SAPI_TARGET) Makefile.am: just what you think. Make sure your target is called "libphpsapi_NNN.a", where NNN is the value of PHP_SAPI. Some testing and fixing probably remains. To make everything hang together, I've done some ugly tricks that I can imagine causing some problems. I've built and run the CGI version and built the Apache DSO.
1999-09-27 16:34:28 +00:00
AC_MSG_CHECKING(whether to force Apache CGI redirect)
AC_ARG_ENABLE(force-cgi-redirect,
[ --enable-force-cgi-redirect
Enable the security check for internal server
redirects. You should use this if you are
running the CGI version with Apache. ],
[
if test "$enableval" = "yes"; then
AC_DEFINE(FORCE_CGI_REDIRECT, 1)
AC_MSG_RESULT(yes)
REDIRECT=1
else
AC_DEFINE(FORCE_CGI_REDIRECT, 0)
AC_MSG_RESULT(no)
REDIRECT=0
fi
],[
AC_DEFINE(FORCE_CGI_REDIRECT, 0)
AC_MSG_RESULT(no)
REDIRECT=0
])
AC_MSG_CHECKING(whether to discard path_info + path_translated)
AC_ARG_ENABLE(discard_path,
[ --enable-discard-path If this is enabled, the PHP CGI binary
can safely be placed outside of the
web tree and people will not be able
to circumvent .htaccess security. ],
[
if test "$enableval" = "yes"; then
AC_DEFINE(DISCARD_PATH, 1)
AC_MSG_RESULT(yes)
DISCARD_PATH=1
else
AC_DEFINE(DISCARD_PATH, 0)
AC_MSG_RESULT(no)
DISCARD_PATH=0
fi
],[
AC_DEFINE(DISCARD_PATH, 0)
AC_MSG_RESULT(no)
DISCARD_PATH=0
])
fi
if test "$PHP_SAPI" = "cgi" ; then
INSTALL_IT="\$(SHELL) \$(srcdir)/install-sh -m 0755 $SAPI_PROGRAM \$(bindir)/$SAPI_CGI"
Generalized server-API build process on UNIX. Each SAPI implementation now has its own directory under sapi/, just like extensions have theirs under ext/. To make the final targets appear in the main dir, the top-level Makefile includes sapi/NN/Makefile.inc from the selected sapi backend. This is a plan Makefile stub without any autoconf substitutions. Each SAPI backend also has its own config.m4 like extensions (read at the end of diversion 2) and config.h.stub files. Each SAPI backend has to contain: config.m4: just like for extensions, this file contains autoconf/automake directives that end up in the configure script. The only difference is that the sapi config.m4 files are read in diversion (output block) 2 instead of 3. The sapi config.m4 files should set two variables: PHP_SAPI (which sapi backend to choose) and SAPI_TARGET (the name of the resulting library or program, previously BINNAME). If they are not specified, they will default to "cgi" and "php", respectively. Makefile.inc: has to exist, has to define "INSTALL_IT" to the command used to install the final target (or ":" for no operation). It also has to define a plain Makefile rule (without autoconf substitutions) to build $(SAPI_TARGET) Makefile.am: just what you think. Make sure your target is called "libphpsapi_NNN.a", where NNN is the value of PHP_SAPI. Some testing and fixing probably remains. To make everything hang together, I've done some ugly tricks that I can imagine causing some problems. I've built and run the CGI version and built the Apache DSO.
1999-09-27 16:34:28 +00:00
fi
AC_MSG_CHECKING(for fhttpd module support)
AC_ARG_WITH(fhttpd,
[ --with-fhttpd[=DIR] Build fhttpd module. DIR is the fhttpd sources
directory, defaults to /usr/local/src/fhttpd.],
[
if test "$withval" = "yes"; then
# fhttpd source directory
withval=/usr/local/src/fhttpd
fi
if test "$withval" != "no"; then
Generalized server-API build process on UNIX. Each SAPI implementation now has its own directory under sapi/, just like extensions have theirs under ext/. To make the final targets appear in the main dir, the top-level Makefile includes sapi/NN/Makefile.inc from the selected sapi backend. This is a plan Makefile stub without any autoconf substitutions. Each SAPI backend also has its own config.m4 like extensions (read at the end of diversion 2) and config.h.stub files. Each SAPI backend has to contain: config.m4: just like for extensions, this file contains autoconf/automake directives that end up in the configure script. The only difference is that the sapi config.m4 files are read in diversion (output block) 2 instead of 3. The sapi config.m4 files should set two variables: PHP_SAPI (which sapi backend to choose) and SAPI_TARGET (the name of the resulting library or program, previously BINNAME). If they are not specified, they will default to "cgi" and "php", respectively. Makefile.inc: has to exist, has to define "INSTALL_IT" to the command used to install the final target (or ":" for no operation). It also has to define a plain Makefile rule (without autoconf substitutions) to build $(SAPI_TARGET) Makefile.am: just what you think. Make sure your target is called "libphpsapi_NNN.a", where NNN is the value of PHP_SAPI. Some testing and fixing probably remains. To make everything hang together, I've done some ugly tricks that I can imagine causing some problems. I've built and run the CGI version and built the Apache DSO.
1999-09-27 16:34:28 +00:00
# For fhttpd 0.3.x
if test -f $withval/servproc.h; then
FHTTPD_INCLUDE=-I$withval/
FHTTPD_LIB=$withval/servproc.o
FHTTPD_TARGET=$withval/
PHP_BUILD_STATIC
PHP_SAPI=cgi
AC_DEFINE(FHTTPD)
AC_MSG_RESULT(yes - fhttpd 0.3.x)
else
AC_MSG_RESULT(no)
AC_MSG_ERROR(Invalid fhttpd directory - unable to find servproc.h under $withval)
fi
else
AC_MSG_RESULT(no)
fi
Generalized server-API build process on UNIX. Each SAPI implementation now has its own directory under sapi/, just like extensions have theirs under ext/. To make the final targets appear in the main dir, the top-level Makefile includes sapi/NN/Makefile.inc from the selected sapi backend. This is a plan Makefile stub without any autoconf substitutions. Each SAPI backend also has its own config.m4 like extensions (read at the end of diversion 2) and config.h.stub files. Each SAPI backend has to contain: config.m4: just like for extensions, this file contains autoconf/automake directives that end up in the configure script. The only difference is that the sapi config.m4 files are read in diversion (output block) 2 instead of 3. The sapi config.m4 files should set two variables: PHP_SAPI (which sapi backend to choose) and SAPI_TARGET (the name of the resulting library or program, previously BINNAME). If they are not specified, they will default to "cgi" and "php", respectively. Makefile.inc: has to exist, has to define "INSTALL_IT" to the command used to install the final target (or ":" for no operation). It also has to define a plain Makefile rule (without autoconf substitutions) to build $(SAPI_TARGET) Makefile.am: just what you think. Make sure your target is called "libphpsapi_NNN.a", where NNN is the value of PHP_SAPI. Some testing and fixing probably remains. To make everything hang together, I've done some ugly tricks that I can imagine causing some problems. I've built and run the CGI version and built the Apache DSO.
1999-09-27 16:34:28 +00:00
],[
AC_MSG_RESULT(no)
Generalized server-API build process on UNIX. Each SAPI implementation now has its own directory under sapi/, just like extensions have theirs under ext/. To make the final targets appear in the main dir, the top-level Makefile includes sapi/NN/Makefile.inc from the selected sapi backend. This is a plan Makefile stub without any autoconf substitutions. Each SAPI backend also has its own config.m4 like extensions (read at the end of diversion 2) and config.h.stub files. Each SAPI backend has to contain: config.m4: just like for extensions, this file contains autoconf/automake directives that end up in the configure script. The only difference is that the sapi config.m4 files are read in diversion (output block) 2 instead of 3. The sapi config.m4 files should set two variables: PHP_SAPI (which sapi backend to choose) and SAPI_TARGET (the name of the resulting library or program, previously BINNAME). If they are not specified, they will default to "cgi" and "php", respectively. Makefile.inc: has to exist, has to define "INSTALL_IT" to the command used to install the final target (or ":" for no operation). It also has to define a plain Makefile rule (without autoconf substitutions) to build $(SAPI_TARGET) Makefile.am: just what you think. Make sure your target is called "libphpsapi_NNN.a", where NNN is the value of PHP_SAPI. Some testing and fixing probably remains. To make everything hang together, I've done some ugly tricks that I can imagine causing some problems. I've built and run the CGI version and built the Apache DSO.
1999-09-27 16:34:28 +00:00
])
INCLUDES="$INCLUDES $FHTTPD_INCLUDE"
dnl## AC_SUBST(FHTTPD_INCLUDE)
AC_SUBST(FHTTPD_LIB)
AC_SUBST(FHTTPD_TARGET)