yea. --Jani
On Thu, 7 Mar 2002, Sascha Schumann wrote: > Hi, > > I'd like to get some input on the new build system. If there > are enough "yea" voices, I could merge it into 4.3.0.. > > The current patch against the CVS is here: > > http://schumann.cx/buildv5.patch > > This version adds support for the test target and PHP_DEFINE > which aims at enabling more fine-grained dependencies and > phasing out the 2000 lines php_config.h. This fine-grained > approach has been used by the BSD kernels and Linux for some > time and is simply necessary for larger systems. > > The system preserves quite a lot of disk space and improves > the speed of the PHP build. > > An overview of the system follows: > > >PHP Build System V5 Overview > >- supports Makefile.ins during transition phase >- not-really-portable Makefile includes have been eliminated >- supports seperate build directories without VPATH by using > explicit rules only >- does not waste disk-space/CPU-time for building temporary libraries > => especially noticeable on slower systems >- slow recursive make replaced with one global Makefile >- eases integration of proper dependencies >- adds PHP_DEFINE(what[, value]) which creates a single include-file > per what. This will allow more fine-grained dependencies. >- abandoning the "one library per directory" concept >- improved integration of the CLI >- several new targets > build-modules: builds and copies dynamic modules into modules/ > install-cli: installs the CLI only, so that the install-sapi > target does only what its name says >- finally abandoned automake (still requires aclocal at this time) >- changed some configure-time constructs to run at buildconf-time >- upgraded shtool to 1.5.4 >- removed $(moduledir) (use EXTENSION_DIR) > >The Reason For a New System > >It became more and more apparent that there is a severe need >for addressing the portability concerns and improving the chance >that your build is correct (how often have you been told to >"make clean"? When this is done, you won't need to anymore). > > >If You Build PHP on a Unix System > > >You, as a user of PHP, will notice no changes. Of course, the build >system will be faster, look better and work smarter. > > > >If You Are Developing PHP > > > > >Extension developers: > >Makefile.ins are abandoned. The files which are to be compiled >are specified in the config.m4 now using the following macro: > >PHP_NEW_EXTENSION(foo, foo.c bar.c baz.cpp, $ext_shared) > >E.g. this enables the extension foo which consists of three source-code >modules, two in C and one in C++. And dependending on the user's >wishes, the extension will even be built as a dynamic module. > >The full syntax: > >PHP_NEW_EXTENSION(extname, sources [, shared [,sapi_class[, extra-cflags]]]) > >Please have a look at acinclude.m4 for the gory details and meanings >of the other parameters. > >And that's basically it for the extension side. > >If you previously built sub-libraries for this module, add >the source-code files here as well. If you need to specify >separate include directories, do it this way: > >PHP_NEW_EXTENSION(foo, foo.c mylib/bar.c mylib/gregor.c,,,-I@ext_srcdir@/lib) > >E.g. this builds the three files which are located relative to the >extension source directory and compiles all three files with the >special include directive (@ext_srcdir@ is automatically replaced). > >Now, you need to tell the build system that you want to build files >in a directory called $ext_builddir/lib: > >PHP_ADD_BUILD_DIR($ext_builddir/lib) > >Make sure to call this after PHP_NEW_EXTENSION, because $ext_builddir >is only set by the latter. > >If you have a complex extension, you might to need add special >Make rules. You can do this by calling PHP_ADD_MAKEFILE_FRAGMENT >in your config.m4 after PHP_NEW_EXTENSION. > >This will read a file in the source-dir of your extension called >Makefile.frag. In this file, $(builddir) and $(srcdir) will be >replaced by the values which are correct for your extension >and which are again determined by the PHP_NEW_EXTENSION macro. > >Make sure to prefix *all* relative paths correctly with either >$(builddir) or $(subdir). Because the build system does not >change the working directory anymore, we must use either >absolute paths or relative ones to the top build-directory. >Correct prefixing ensures that. > > >SAPI developers: > >Instead of using PHP_SAPI=foo/PHP_BUILD_XYZ, you will need to type > >PHP_SELECT_SAPI(name, type, sources.c) > >I.e. specify the source-code files as above and also pass the >information regarding how PHP is supposed to be built (shared >module, program, etc). > >For example for APXS: > >PHP_SELECT_SAPI(apache, shared, sapi_apache.c mod_php4.c php_apache.c) > > > >General info > >The foundation for the new system is the flexible handling of >sources and their contexts. With the help of macros you >can define special flags for each source-file, where it is >located, in which target context it can work, etc. > >Have a look at the well documented macros >PHP_ADD_SOURCES(_X) in acinclude.m4. > > - Sascha Experience IRCG > http://schumann.cx/ http://schumann.cx/ircg > > > > -- -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php