delta/php-git.git/scripts/config-stubs, branch php-4.3.0 git.php.net: repository/php-src.git - Add one 'level' more (0 first, 9 last) 2002-10-21T03:07:23+00:00 foobar sniper@php.net 2002-10-21T03:07:23+00:00 11a1519e51ce1964a92679357d789d5b4362f5c9 # Sascha, maybe we should use that apache2 config-stubs instead? 
# Sascha, maybe we should use that apache2 config-stubs instead?
Fix special treatment of zlib by introducing the Apache concept 2001-05-11T20:09:31+00:00 Sascha Schumann sas@php.net 2001-05-11T20:09:31+00:00 7566cf7f27ad3615f4d4e0b012713070733f69a4 of config.m4 hierarchies. 
of config.m4 hierarchies.
Generalized server-API build process on UNIX. Each SAPI 1999-09-27T16:34:28+00:00 Stig Bakken ssb@php.net 1999-09-27T16:34:28+00:00 2a854ca8b9e94ea75e949edb1283157b0daad617 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. 
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.
First commit of re-structuring phase one. We have started using automake in 1999-04-17T00:37:12+00:00 Stig Bakken ssb@php.net 1999-04-17T00:37:12+00:00 257de2baded9330ff392f33fd5a7cc0ba271e18d sub-directories and started to move extension code into ext/<name>. For now, I have moved the "standard" extension (which is quite a mix of everything right now) and the GD extension into their own subdirs in ext/. The configure script now also runs configure in the libzend directory automatically and makes sure php4 and libzend use the same config.cache file. To avoid running configure in libzend, use the --no-recursion option. "make" in php4 also builds libzend now. The Apache module doesn't compile right now, but a fix for that is coming up. 
sub-directories and started to move extension code into ext/<name>.  For now,
I have moved the "standard" extension (which is quite a mix of everything
right now) and the GD extension into their own subdirs in ext/.
The configure script now also runs configure in the libzend directory
automatically and makes sure php4 and libzend use the same config.cache file.
To avoid running configure in libzend, use the --no-recursion option.
"make" in php4 also builds libzend now.
The Apache module doesn't compile right now, but a fix for that is
coming up.