Hi Christoph, > -----Original Message----- > From: Christoph M. Becker <cmbecke...@gmx.de> > Sent: Monday, June 7, 2021 11:42 PM > To: Anatol Belski <weltl...@outlook.de>; Nikita Popov > <nikita....@gmail.com> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows > > On 07.06.2021 at 13:32, Anatol Belski wrote: > > > 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. > This would be nice, but a similar approach didn't work in the past. Please see how Python or node.js deal with this. The suggested way, PECL will be moving away from a good practice, not improve, and likely lead back the chaos it was before. It's not about assumptions, there was none before. As there's no resources on the team to maintain this, it's a clear story, but probably should mention the likehood of the consequence clearly, too. A good way would be first create a new path and ensure it can replace the old one, not just abandon the old one and hope for best.
Regards Anatol
