mirror of
https://github.com/php/php-src.git
synced 2025-08-15 21:48:51 +02:00
eb76a83008
PHP_DEFINE was introduced with the PHP 5 build system9d9d39a0deand then refactored via350de12bc2. This was once used to put defined constants into a single file to have more fine-graned dependencies (atomic includes). Since no known PHP extension is using this and it makes very little sense to use this, this M4 macro can be removed in favor of the Autoconf native way using AC_DEFINE and the usual included files php_config.h and config.h. - Generated unused include directory removed - Remove include dir from DEFS - Remove also include dir from PDO checks
119 lines
4.1 KiB
Markdown
119 lines
4.1 KiB
Markdown
# PHP build system V5 overview
|
|
|
|
* supports Makefile.ins during transition phase
|
|
* not-really-portable Makefile includes have been eliminated
|
|
* supports separate 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
|
|
* 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
|
|
* 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:
|
|
|
|
```m4
|
|
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, depending on the user's wishes, the extension will
|
|
even be built as a dynamic module.
|
|
|
|
The full syntax:
|
|
|
|
```m4
|
|
PHP_NEW_EXTENSION(extname, sources [, shared [,sapi_class[, extra-cflags]]])
|
|
```
|
|
|
|
Please have a look at `build/php.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:
|
|
|
|
```m4
|
|
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`:
|
|
|
|
```m4
|
|
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
|
|
`$(srcdir)`. 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
|
|
|
|
```m4
|
|
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:
|
|
|
|
```m4
|
|
PHP_SELECT_SAPI(apache, shared, sapi_apache.c mod_php.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
|
|
`build/php.m4`.
|