* fix(installer): keep the embed build inside its own prefix
The libphp.so installer reuses the configure options of the PHP already on
the machine so the private build matches it feature for feature. A
distribution build records where *it* installs, though, and those paths are
absolute. On Debian and Ubuntu the options carry --mandir=/usr/share/man,
--includedir=/usr/include, --libdir, --libexecdir, --sysconfdir and
--localstatedir. Inherited unchanged, they survive the --prefix rewrite, and
`make install` tries to write into system directories:
Installing PHP CLI man page: /usr/share/man/man1/
cp: cannot create regular file '/usr/share/man/man1/#INST@3023727#': Permission denied
make: *** [Makefile:265: install-cli] Error 1
Fatal error: Unable to install libphp.so: Command failed: make install
So the build only completed for root, or inside a container where the user
owns /usr. Everyone else got a PHP compiled from scratch and then thrown
away at the last step.
Two further options escape the same way. --program-suffix=8.3 installs the
binaries as php8.3 and php-config8.3, but LibPhpInstaller::installedVersion(),
writePhpIni() and UnixPlatform::findPhpConfig() all look for the plain names,
so a build that got past `make install` still looked like it had produced
nothing. --cache-file points at the distribution's build directory
(/tmp/buildd/nonexistent/config.cache), a path that does not exist here and
whose answers were recorded for a different prefix.
Drop all of them. Autoconf derives every installation directory from --prefix
when it is absent, so the private build lands entirely under the requested
prefix: bin/php, lib/libphp.so, include/php and share/man/man1. Options that
name a *dependency* rather than a destination, such as --with-zlib=/usr and
--with-layout=GNU, are untouched; the built PHP still matches the one it was
derived from.
* fix(installer): offer an existing build before asking to make one
Running a build twice asked four questions to arrive at the answer it
already had:
The current PHP installation does not provide libphp.so: /usr
Build a private PHP embed library now? [Y/n]
PHP version [8.5.10]:
Install directory [/home/alganet/.typephp]:
PHP 8.5.10 with libphp.so already exists in /home/alganet/.typephp; use it? [Y/n]
The reuse check sat at the bottom because it needs a version and a
directory, and those were read from the prompts. But both have defaults
that are known without asking anyone: the directory this installer always
proposes, and the PHP that is running it. That is the case being answered
here, so it can be offered first.
Ask it up front. Accepting now ends the exchange at one question, and the
`--prefix` rewrite no longer has to be reasoned about at all. The later
check stays for a directory or version typed by hand, and is skipped when
the answers repeat the defaults, so the same question is never asked twice.
ensure() also fetched the release list from php.net before looking for an
existing build, so the reuse path made a network round trip to learn the
URL of an archive it was not going to download. Move the fetch next to the
install that needs it.
Nothing recorded PHP_HOME anywhere but this process, and that has not
changed: a fresh run still has to rediscover the build. Being asked once
instead of four times is the part that is worth fixing separately.
- Updated swoole/phpx dependency from v2.3.9 to v2.3.10
- Created InteractiveConsole class for terminal interactions
- Implemented LibPhpInstaller with automatic PHP embed library building
- Added LinuxPackageManager detection for dependency installation
- Integrated PhpBuildConfiguration for proper PHP compilation options
- Added documentation for libphp.so automatic building feature
- Added unit tests for the new installer components
- Integrated installer into build pipeline for Linux platforms
韩天峰
Alexandre Gomes Gaigalas