I presume that the old PHP_EXENTSION(....) still works in V5 so modules outside the php tree can keep using it? ... and put in dnl PHP_EXENTSION_NEW..... so it's V5 ready...
regards alan > > >On Thu, 7 Mar 2002, Sascha Schumann wrote: > >> 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.. >> > >go for it (or should I say "yea" :) > >Derick > >> 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 >> > >---------------------------------------------------------------------- > PHP: Scripting the Web - [EMAIL PROTECTED] > All your branches are belong to me! > SRM: Site Resource Manager - www.vl-srm.net >----------------------------------------------------------------------- > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
