On 16.12.2021 at 22:31, Horváth V. wrote: >> I think the answer should be that _eventually_ they should have to >> migrate, but in the interim we must maintain two build systems. > > You are right on the first point, but it is not a requirement for > php-src to be managed by anything other than CMake to maintain phpize > functionality for existing 3rd party software making use of it. From a > quick look, I can tell that it just copies some files that can be > generated/configured by CMake if necessary.
It seems to me the point is the autoconf (emulated on Windows) stuff we have in php-src which is used by third party extensions in their config.m4 and config.w32 files. 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, I'm all for switching to CMake, especially because building on Windows is a major issue for many extension maintainers, since the build chain is mostly undocumented, and is missing a lot of features, like requiring a certain minimum version of a library, or certain features of it. Wrt. requiring some package manager, such as Conan: I think we should try to keep the build requirements at a minimum. Regarding the discussion platform for a potential CMake migration, maybe a Github project could be helpful. Regards, Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
