This enhances the makidst script:
- integrate both snapshot and makedist scripts together
- add help and options
- generated files are created in the php-src repository directly
- other minor enhancemenets such as CS fixes
- functionality moved from the Makefile to only shell script
- Add missed patching of the Zend Parsers to the main build step
- Add all *.tmp files to gitignore
Normalization include:
- Use dnl for everything that can be ommitted when configure is built in
favor of the shell comment character # which is visible in the output.
- Line length normalized to 80 columns
- Dots for most of the one line sentences
- Macro definitions include similar pattern header comments now
The vcsclean script is really only a wrapper for a git clean command.
Developers should use the more proper and clear native Git command
directly instead:
`git clean -Xfd`
This script hasn't been used since using PEAR as a package manager for
PHP extensions since it is using Makefile.in as an indicator if the
current directory is extension. Instead of this script extensions can
be packaged differently and more properly with either current PEAR
or with some other manual method.
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.
Commit 4e7064d173 removed the usage of
`aclocal.m4`. When using Git repositories, many times cleaning of the
generated files is not done prior to running phpize or buildconf. For
example:
git clone git://github.com/php/php-src
cd php-src
git checkout PHP-7.3
./buildconf
./configure
git checkout PHP-7.4
./buildconf # -> warnings
./configure # -> errors
To not accidentally include `aclocal.m4` file in the generated configure
this enhances build system experience a bit more by removing aclocal.m4
file prior to start building configure file using phpize or buildconf.
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
Autoconf defines PACKAGE_* symbols:
- PACKAGE_NAME
- PACKAGE_VERSION
- PACKAGE_TARNAME
- PACKAGE_STRING
- PACKAGE_BUGREPORT
- PACKAGE_URL
and appends them to the generated config.h.in files. With AC_INIT change
via afd52f9d99 where package version, URL,
bug report location and similar meta data are defined, these
preprocessor macros are then non empty strings in the generated
configuration header file. When using phpize, PHP shares the config
files in extensions, warnings of redefined macros appear, such as:
- `warning: 'PACKAGE_NAME' macro redefined`
This patch now disables these non utilized symbols in the generated
config header files.
Better practice would be to include only API specific headers where
needed but this would require even more refactorings. Some extensions
such as pcre, pgsql, and pdo_pgsql solve this issue by undefining some
of these symbols before including the library configuration headers in
the code also. Because these symbols can be defined by any library which
uses Autotools.
Additionally, the unused PACKAGE_* symbols were cleaned for the bundled
libmbfl library and with this patch not needed undef code removed.
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.
This patch refactors these macros to also checks for the required given
versions of bison and re2c.
- PHP_PROG_RE2C and PHP_PROG_BISON take optional args - minmimum version
required, and bison also excluded versions.
- Instead of caching values this uses manual checking and messaging
outputs.
- It looks like the minimum version of RE2C 0.13.4 is working ok so far.
The genfiles script improvements:
- Add make override in genfiles
- Move checkings from makedist to genfiles
- Refactored output messages
- Various minor enhancements
With Bison 3.0 some directives are deprecated:
- %name-prefix "x" should be %define api.prefix {x}
- %error-verbose should be %define parse.error verbose
Bison 3.3 also started emiting more warnings and since PHP souce parsers
are not POSIX compliant this patch fixes this as pointed out via
495a46aa1d.
The more proper place for shell scripts dedicated for development, and
releasing PHP should be the scripts/dev directory. Having a cleaner root
project directory helps find the main README.md and files relevant to
install PHP.
These scripts are also used by the release managers mostly who create
release packages and aren't used often by the majority of developers
working on and installing PHP.
The AC_PROG_CC_C_O macro checks if compiler can use both -c and -o
options together and if not it defines the NO_MINUS_C_MINUS_O symbol.
It is not used in current codebase and therefore removed.
The PHP_EXTENSION macro was used before the introduction of the updated
build system in the 9d9d39a0de. The
extensions at that time possibly still used the Makefile.in and Automake
and the PHP_EXTENSION macro has been replaced with the PHP_NEW_EXTENSION
macro.
Today, the once deprecated macro can be removed in favor of only
PHP_NEW_EXTENSION macro.
At the time of this commit, there is a dedicated folder for development
related tools and such scripts might fit better there to not bloat the
project root directory too much.
Move snapshot to scripts/dev/snapshot
This patch follows previous license year ranges updates. With new
approach source code files now have simplified headers with license
information without year ranges.
The Autoconf macro AC_CONFIG_AUX_DIR can set the location of the
auxiliary build tools such as config.guess, config.sub, and bundled
libtool scripts and moves these bundled files from the root directory
to the build subdirectory.
Additionally some changes in this context or as a part of obsoletion:
- The LT_TARGETS variable in build/build2.mk file was once used as a part
of the Automake step. It's not used anymore and has been refactored to
separate makedist script directly.
- ltconfig is not used anymore since libtool 1.4+
cf8d1563c2
- phpize file locations for the config.guess, config.sub, and ltmain.sh
has been refactored accordingly.
The `mkdep.awk` file was part of the previous *nix build system and was
used to create a .deps file with a list of dependencies that could be
processed by Automake further on.
Newer build system was done via 9d9d39a0de
and outdated files removed via 22815419f8
so the current file in the PHP source code is not used anymore.
Additionally, the *.slo files were processed by this file. The *.slo
files also used to be generated by older libtool so today, these don't
get generated anymore.
The `.deps` file(s) was once used by Automake and created to write
dependencies to it. The file creation has been removed via the commit
779c11af21.
The phpize and ./configure script create a redundant .deps file in a
PECL extension directory which might cause confusions why is it used.
Today it is no longer relevant so this redundant artefact can be
removed in the phpize configure script.
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
The Autoconf AC_PRESERVE_HELP_ORDER macro has been available since
Autoconf 2.59c [1] and in PHP it has been called conditionally on two places
to support older Autoconf versions. With recent updates and the macro
can be called unconditionally.
[1] http://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS
This patch syncs and bumps the minimum required version of Autoconf for
the `phpize.m4` script and the main `configure.ac` from previously mixed
2.64 and 2.59 to 2.68.
At the time of this writing Autoconf 2.63 is still the version on
Centos 6, however by the PHP 7.3 release current systems out there
should all have pretty much updated Autoconf versions to 2.64+ at
least. Centos 7 already has Autoconf 2.69, for example.
This provides more options to update and get current with the *nix
build system and also avoids broken builds in certain cases as pointed
out in the relevant discussion [1].
Additionally, phpize also already provides the `AX_CHECK_COMPILE_FLAG`
Autoconf Archive m4 file that has Autoconf 2.64 minimum requirement.
Autoconf 2.68 was released in 2010, 8 years ago, relative to this patch.
[1] https://github.com/php/php-src/pull/3562
This patch makes several scripts and PHP development tools files
executable and adds more proper shebangs to the PHP scripts.
The `#!/usr/bin/env php` shebang provides running the script via
`./script.php` and uses env to find PHP script location on the system.
At the same time it still provides running the script with a user
defined PHP location using `php script.php`.
