Hi internals, > > Removing the centralized PECL builder and dependency manager would most > > likely lead to a huge regression in the support and manageability. Right > > now there's one place pecl.php.net to go for the non core extension builds > > and any dependencies are guaranteed to be non conflicting. If this gets > > decentralized, the effort is moved to the extension maintainers which will > > most likely mean the chaos in where to get a DLL, DLL hell issues, absent > > DLL because the configuration is hard. This will steadily lead to the > > situation that was there before. > > > > IMO even keeping the basic version of the centralized approach even having > > a sporadic chance to fix issues is a far better way to go than dropping the > > existing achievements. Also in the long run, other approaches like moving > > to vcpkg for deps, checking on other things like cmake and pickle might be > > a good way, if there's a community interest. More volunteers on the > > community side would be great in this sense, too. > > Good points, thank you for bringing them up! I have to fully agree that > we should not drop the central point of distribution (i.e. > windows.php.net). I don't think, however, that we can stick with the > current PECL build system for long. Maybe the biggest issue is that > extension maintainers may see automatic DLL builds as a given, or at > least may not be able to fix things, because only few have access to the > build machine. And even if that was not an issue, not many more would > know where to look at. In other words, the bus factor is very low, and > it may happen at some point in time, that no new DLLs would be built for > *any* extension. > > This is why I still think it would be good to shift some of the burden > of maintaining Windows builds to extension maintainers is a good thing. > It is not about making their job harder, but rather about preventing > serious issues, and also to correct expectations; extension maintainers > might well assume that their extension is supported on common Linux > distros, but they shouldn't *assume* it is supported on Windows as well > (let alone that the dependency libraries have fixes for all known > relevant security issues). > > Even if extensions are developed solely on Linux (and most are, as far > as I know), they should have some Windows CI (at least doing the actual > builds; better to run the test suite as well, of course), and that > shouldn't be a real problem – there are several CI providers which are > free for OSS projects. We should do our best to provide them with > appropriate tools, so Windows CI integration can be set up as easily as > for Linux phpize builds. That would not solve the issues regarding > dependencies, but appears to be a reasonable first step in the right > direction.
With the release for php 8.1.0 stable happening Nov 25 (https://wiki.php.net/todo/php81), what decision ended up being made (I couldn't tell if it was still being discussed from the thread)? To publish Windows DLLs for PECLs for PHP 8.1 after 8.1.0 stable or not to publish? I saw the proposal but didn't see any public announcement of plans, and usually DLLs had been published earlier. - If there are plans to get 8.1.0 working, what work is remaining (e.g. is there an issue tracker/list of tasks)? (I'm a Linux user, but I'd hope even if the windows team didn't have time, developers from large organizations may have time to look into those issues or get builds for individual extensions working, if those organizations used Windows and were migrating to php 8.1) https://externals.io/message/114751#114759 sounded like there were plans to build DLLs for PECLs with GitHub workflows instead of the current machine, but I'm not sure of the status of those plans. If php 8.1 DLL support was being dropped, I saw nothing communicating a change (or status of getting DLL builds+publishing working for php 8.1) in the following places: - https://news-web.php.net/group.php?group=php.internals.win - https://marc.info/?l=pecl-dev&w=2&r=1&s=dll&q=b - https://windows.php.net/ ("Where are the PECL DLLs" is an unrelated announcement that was resolved) - https://twitter.com/official_php As an arbitrary example, https://pecl.php.net/package/xdebug/3.1.1/windows mentions "In case of missing DLLs, consider to contact the PHP for Windows Team." - If DLL publishing would end up being discontinued (or delayed) for PHP 8.1+, the footer common to all PECLs should be updated to indicate that. I was delaying working on publishing DLLs for PECL releases until I was certain what the decision was, or if DLLs would continue to be published. Thanks, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
