Adding two exit early safeguards in the *nix configuration build script:
1) Given the initial cd into the build tree fails (the project root),
the `buildconf` script exits with non-zero status (failure).
2) Given the grep command does not exist or `configure.ac` AC_INIT [1]
expectations are unmet, the buildconf script exits non-zero.
Additionally quoting the pathname to cd into and the empty CD_PATH
parameter for portability, also for systems that are using a
non-portable pathname [2] for the build tree.
The initial CD safeguard has been applied to the `buildconf` and
four more scripts:
- build/genif.sh
- scripts/dev/credits
- scripts/dev/genfiles
- scripts/dev/makedist
Rationale:
Cd-ing into the project root should always prematurely exit w/ FAILURE
as a required precondition for its invocation has not been met. This
should never go unnoticed as it always requires user intervention.
Similar and more specifically to the PHP build on *nix systems, the
grep command is required early to obtain the `php_extra_version` from
configure.ac. Previously, if the grep command is missing (or failing
due to not matching the line with the AC_INIT macro [1]), the internal
dev parameter would always be zero (0) which can easily result in the
situation that the configure script is not being rebuilt. This is
cumbersome as the rebuild of a configure script is more likely required
with checked-out dev versions under change rather than an already
properly set-up build environment on a dedicated build or release
system. Missing the fact that either the grep utility is missing or
the expectation of having the AC_INIT macro in configure.ac is unmet
should never go unnoticed as it always requires user intervention.
[1]: https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Initializing-configure.html
[2]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271
Closes GH-16717.
When Autoconf version includes also development patch character (for
example, 2.72c), such as in unreleased Autoconf versions, this now
sets proper number for checking minimum required Autoconf version.
First step when creating the `configure` script is currently using
make. This is helpful when developing buildsystem to only rebuild
`configure` and `main/php_config.h.in` files when one of the *.m4
or configure.ac file changes and saves the developer time a little.
Realistically however, it is not needed that much considering the
times of several seconds to fully rebuild the configure script and
configuration header. The next step when running the `configure`
script is much more time consuming so performance on buildconf
level is a bit questionable and won't be noticed on today's
systems.
Additionally:
- buildconf now removes cache and all targets and uses -f option on
the first step i.e. autoconf. The autoheader does not need the -f
option in this case.
Closes GH-4437
The buildmk.stamp file has been created by the *nix build checking step
to run the check step only once. Instead of poluting the project root
directory, the stamp file can be also omitted. Performance difference is
very minimal to not justify having the stamp check at all today anymore.
This patch integrates the buildcheck.sh to buildconf script directly.
The force option used to only remove the Autoconf cache files. Now it
also removes entire configure file so the configure file always gets
rebuilt when needs be done.
Additionally, the buildconf now also accepts the shorter version of the
force option:
buildconf -f
The acinclude.m4 file is in a usual Autotools build processed with
Automake's aclocal tool. Since PHP currently doesn't use Automake and
aclocal this file can be moved into the build directory. PHP build
system currently generates a combined aclocal.m4 file that Autoconf
can processes automatically.
However, a newer practice is writing all local macros in separate
dedicated files prefixed with package name, in PHP's case PHP_MACRO_NAME
and putting them in a common `m4` directory. PHP uses currently `build`
directory for this purpose.
Name `php.m4` probably most resembles such file for PHP's case.
PHP manually created the aclocal.m4 file from acinclude.m4 and
build/libtool.m4. Which is also not a particularly good practice [1], so
this patch also removes the generated alocal.m4 usage and uses
m4_include() calls manually in the configure.ac and phpize.m4 files
manually.
- sort order is not important but can be alphabetical
- list of *.m4 files prerequisites for configure script generation
updated
- Moving m4_include() before AC_INIT also removes all comments starting
with hash character (`#`) in the included files.
[1] https://autotools.io/autoconf/macros.html
There is now only a single M4 macro in the legacy acinclude.m4 file. A
separate acinclude file was once used with a standalone Zend engine
building but with current build system this can be simplified a bit.
Changes:
- Joins build/build.mk and build/build2.mk files together since there
isn't any practical reason for having two different files with the
current build system.
- Makefile is now more portable. All special syntaxes are omitted, for
example, a conditional assignment operators `?=`. This makes buildconf
more useful on Solaris make derivative, so there is no longer need to
override make with gmake: `MAKE=gmake ./buildconf`.
- Suppressing autoconf and autoheader warnings is not needed anymore
with current build system. Instead, the option `-Wall` has been used
when running `./buildconf --debug` to get more useful debug info
about current M4.
The `generated_lists` file is generated as a helper for build related
Makefile to include a list of *.m4 files prerequisites. When some of
these *.m4 files change, the configure script is regenerated when
buildconf is run. This can be simplified using dynamic environment
variable passed to the Makefile directly so it avoids another file from
being generated in the project root directory and shipping it with the
PHP release or creating a dedicated gitignore rule.
This is portable across all POSIX compatible makes So this patch
includes GNU Make, and everybody elses' make derivative support.
Since Autoconf 2.53 the AC_INIT call with only a single argument has
been made obsolete and now includes several other optional arguments to
make installation experience a bit better by providing program version
and links to the project in the `./configure -h` output. This patch also
updates win build version. The phpize.m4 AC_INIT has been updated with
the call without arguments.
Changes:
- Added a short introduction what this script does
- Added usually the expected -h and --help options with explanation
for a reason for this script and its usage.
- Messages changed a bit so the PHP installation procedure becomes
simpler without needing to constantly remind the reader what to run
and what not in the documentations and installation instructions.
- cd into current working directory of the buildconf (this enables
running the script from other locations and inside other scripts).
- check if make exists
The $Id$ keywords were used in Subversion where they can be substituted
with filename, last revision number change, last changed date, and last
user who changed it.
In Git this functionality is different and can be done with Git attribute
ident. These need to be defined manually for each file in the
.gitattributes file and are afterwards replaced with 40-character
hexadecimal blob object name which is based only on the particular file
contents.
This patch simplifies handling of $Id$ keywords by removing them since
they are not used anymore.
configure.ac was introduced in 2001 with automake-1.15 and autoconf-2.50
to replace the file named configure.in.
Autotools is preparing to remove configure.in in Automake 2.0.
All new software should be using configure.ac.
This also fixes Bug #69770 where extensions are creating configure.in
Signed-off-by: Brian Evans <grknight@gentoo.org>
- added support for externally built modules,
- improved support for in-tree shared modules,
- fixed diversion bugs,
- configure displays some informative messages,
- faster static build
(libtool isn't used anymore for compiling non-PIC objects),
- dependencies comparable to automake's without requiring GNU make or GCC,
- working make clean for non-GNU makes.
- PHP-specific changes are easier to maintain
- it removes one dependency for users (i.e. GNU vs. FreeBSD ports)
I have not removed the libtool check in buildconf, since libzend/TSRM still
depend on a local version of libtool.