We cannot break that without giving sufficient time to the respective maintainers to update these extensions to use the new CMake build system. If we can maintain both build chains for some years
Yes, gradually phasing the current build system out is the most pragmatic choice, although it will incur some extra maintenance cost for the time it's still in use, but it's better to do something sooner than later. This will also allow php-src to drop the Windows SDK altogether that was recently moved to the GH org, because Microsoft stopped maintenance.
Wrt. requiring some package manager, such as Conan: I think we should try to keep the build requirements at a minimum.
I have absolutely no intention of dependency manager lock-in. Conan allows transparent integration with CMake and it also makes grabbing things like bison trivial on Windows. For Linux users, they can happily continue to use their system dependency manager *or* opt into using Conan, but the choice is left up to the one building the project, not the project itself. I have this example repository I have created to show transparent Conan usage with a CMake project: https://github.com/friendlyanon/cmake-init-conan-example The only way the project ever interacts with Conan is if the preset used to configure inherits from the "conan" preset, otherwise CMake will not be provided with additional prefixes to search from Conan. Please note that this repository was made before I was made aware that using their utility script "conan.cmake" isn't really the best way to use Conan in CMake projects and it's really intended as stopgap solution. I will look into profiles and make use of Conan properly eventually, which means I will use the above project as a playground to test things first.
Regarding the discussion platform for a potential CMake migration, maybe a Github project could be helpful.
Either way works for me as long as people with questions can reach me or other interested parties regarding CMake. I guess GH has the added advantage of better discoverability than mailing lists. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
