Hello Tim, On Wed, Dec 6, 2023 at 9:05 AM Tim Starling <tstarl...@wikimedia.org> wrote:
> Have you considered keeping the support matrix in the registry > database, instead of in pecl.json? Then it can be updated with new > build/test information after release. We do it for windows, used by pickle, you can see one part here: https://windows.php.net/downloads/php-sdk/deps/dllmapping.json The other parts being part of each extension. It could be achieved similarly for linux package managers, maybe maintained by them directly. A few years back, I made some tests on windows and linux using https://conan.io/ and https://vcpkg.io/, they both work on most platforms PHP supports and also have cmake integration (php build using cmake has been worked done, very nicely :). Having maintained these parts for many years, dealt with 3rd parties (developers of librairies, distro packages maintainers, etc) as well as dealt with many end users (php developers), I must say I would absolutely not start to define our own things but rely as much as possible on the well working existing solutions. On the same topic, npecl's requirements (why not a RFC/proposal btw?) are kind of out of sync with what I have seen and still see. F.e., doing it outside the composer ecosystem will most likely create a niche and not a wide adoption.There have been a lot of efforts put into similar topics since 5.3 and a lot of learning, it may be a good thing to learn from them. There are also tools now available to give developers out of box tools to define whatever environments they may need and switch between them within a click or command line (Laravel community created a few good ones, mac for the biggest one, and other platforms), having them rely on php's platform for the core and non core extensions (including their respective deps) will be amazingly helpful. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
