Re: [PHP-DEV] Vote on New Build System

[derick]

Hello,

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 f

Re: [PHP-DEV] Vote on New Build System

[Edin Kadribasic]

> 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..

+ 1

Edin



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote on New Build System

[Alan Knowles]

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 suppos

Re: [PHP-DEV] Vote on New Build System

[Jani Taskinen]

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 sourc

Re: [PHP-DEV] Vote on New Build System

[Marko Karppinen]

>   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..

I'd love to see this in 4.3.0.

--Marko


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote on New Build System

[Sascha Schumann]

On Thu, 7 Mar 2002, Alan Knowles wrote:

> 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...

Yes.  The system includes a scanner for Makefile.in templates
which is invoked, when modules call PHP_EXTENSION, so that
the transition should be painless for most modules.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Vote on New Build System

[Marc Boeren]

> 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..

Yea!

- Marc.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote on New Build System

[Brian Foddy]

Sascha Schumann wrote:
 
> 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.
> 


I think I'm following this, but let me stress as the developer
of php-tuxedo (http://php-tuxedo.sourceforge.net) that its getting more
and more likely that PHP will be linking in complex libraries 
(includes and libs) perhaps not in the original PHP distribution. 

Another thing I've seen in my project is that the exact libraries
Tuxedo requires vary from Tuxedo version to version.  So capabilities
to have the make process perform some dynamic adjustments would be
nice.  I think its just I need to get better at m4, but I haven't
invested the time yet.

Overall, I like the goals you outlined and your results look promising.

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php