Installation prefix isn't replaced at cmake --install <build-dir> --prefix ...

[petk]

The installation prefix is the path where the built files are copied to on the system, when doing the installation phase. In Autotools it can be set at the configure phase only. For example:

./configure --prefix=/usr

In the installation phase there is also INSTALL_ROOT to be able to temporary install the built files to a staging directory (this is in practice used on some systems where some additional pre-installation stuff is done):

make INSTALL_ROOT=/package/stage install

Here the /package/stage will then include all the built files together with the installation prefix:

/package/stage/usr/bin/php
/package/stage/usr/include/php/main/php_config.h
...

The PHP's INSTALL_ROOT is more commonly named DESTDIR in other Autotools and C-based projects.

In CMake, the install prefix can be set at the configure phase using the CMAKE_INSTALL_PREFIX variable, or the --install-prefix option:

cmake -B <build-dir> -S <source-dir> -DCMAKE_INSTALL_PREFIX=/usr
# or
cmake -B <build-dir> -S <source-dir> --install-prefix=/usr

Or in the CMake presets file with the installDir field. For example, the CMakePresets.json:

{
  "version": 3,
  "configurePresets": [
    {
      "name": "default",
      "displayName": "PHP configuration",
      "description": "Configuration with the commonly used PHP extensions enabled",
      "installDir": "/usr",
      "binaryDir": "${sourceDir}/php-build/default"
    }
  ]
}

Or it can be also overridden at the installation phase. For example:

cmake --install <build-dir> --prefix /usr

There is also the DESTDIR environment variable, which acts like the INSTALL_ROOT in PHP:

DESTDIR=/package/stage cmake --install <build-dir> --prefix /usr

Therefore it is a common-practice to use the generator expression in CMake files $<INSTALL_PREFIX> that gets properly replaced based on the different phase and its value (either in the configuration and generation phase or in the installation phase).

PHP, however, uses the prefix value also in the C header files at the build phase. For example, in main/build-defs.h or in main/php_config.h. So the prefix defined in the installation phase won't match the prefix from the configure
phase in these header files. Meaning, the cmake --install <build-dir> --prefix <prefix> is at the time of writing not handled properly in this build system yet unless some heavy refactoring is done in PHP.

Where prefix is used in PHP or in this repository files:

• pkg-config templates (this is resolved in the CMake module by additionally replacing the $<INTALL_PREFIX> at the install step
• php-config and some other script files generated from templates (this can be still resolved similarly to pkg-config templates by adjusting the CMake command configure_file())
• PHP_EXTENSION_DIR, PHP_CONFIG_FILE_PATH, PHP_CONFIG_FILE_SCAN_DIR,
• main/build-defs.h.in and in various preprocessor macros, such as PHP_PREFIX, PEAR_INSTALLDIR, PHP_EXTENSION_DIR, PHP_BINDIR, PHP_LIBDIR, ... (this is very difficult to resolve properly as it would require the installation step to rebuild the C code; ideally it would be some sort of a dynamic configuration value to be read from somewhere else than being hardcoded in the header files)