Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114774
To: Anatol Belski <weltling@outlook.de>, Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <581375a1-e18c-c88f-3bc4-557420ea15a3@gmx.de>
 <CAF+90c_3A4o7QK--HxeJDaNQuFvwt9v+m=Re1Y4dDMCfvKm0Nw@mail.gmail.com>
 <9bc4fef7-d144-5623-da96-75516d28c163@gmx.de>
 <CAF+90c80xMLzq6z4=M5-rkGT58qRp4=f-+Me6M3kgaHW3KeGig@mail.gmail.com>
 <AM0PR05MB5171AD124710395E39515E3FBA389@AM0PR05MB5171.eurprd05.prod.outlook.com>
Message-ID: <31f6ba8d-5111-0948-40fe-943ade6f641c@gmx.de>
Date: Mon, 7 Jun 2021 23:42:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <AM0PR05MB5171AD124710395E39515E3FBA389@AM0PR05MB5171.eurprd05.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows
From: cmbecker69@gmx.de ("Christoph M. Becker")

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 n=
ow 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 de=
centralized, the effort is moved to the extension maintainers which will m=
ost likely mean the chaos in where to get a DLL, DLL hell issues, absent D=
LL because the configuration is hard. This will steadily lead to the situa=
tion that was there before.
>
> IMO even keeping the basic version of the centralized approach even havi=
ng 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 mo=
ving to vcpkg for deps, checking on other things like cmake and pickle mig=
ht 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 =E2=80=93 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.

Thanks,
Christoph