Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114757
MIME-Version: 1.0
References: <581375a1-e18c-c88f-3bc4-557420ea15a3@gmx.de>
In-Reply-To: <581375a1-e18c-c88f-3bc4-557420ea15a3@gmx.de>
Date: Mon, 7 Jun 2021 10:02:24 +0200
Message-ID: <CAF+90c_3A4o7QK--HxeJDaNQuFvwt9v+m=Re1Y4dDMCfvKm0Nw@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002b2fdb05c4287776"
Subject: Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000002b2fdb05c4287776
Content-Type: text/plain; charset="UTF-8"

On Sun, Jun 6, 2021 at 3:26 PM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> Hi all,
>
> on Tuesday, PHP 8.1.0alpha1 is supposed to be tagged, and since I don't
> have the capacity to do these builds manually (as currently done with
> the PHP 8.0 builds), I've set up an automation which does the builds on
> GH action runners[1].


To clarify, this builds the binary Windows release artifacts? Automating
that using GH actions is great.


> This should likely be integrated into php-src or
> php-sdk, whereyby the latter needs to be forked into a php organization
> repo as soon as possible, since there is a pending commit regarding the
> exclusion of yet unsupported PGO training scenarios, and we also should
> roll a new SDK release, and update some of the bundled tools.
>

Is php-sdk referring to https://github.com/microsoft/php-sdk-binary-tools?
Having this in the PHP organization sounds reasonable, though I don't
really follow your reasoning. How is the exclusion of PGO training
scenarios relevant here? Is the concern here that Microsoft will not be
maintaining the SDK for new PHP versions, so the PHP organization should
take over doing that going forward?

Anyhow, if these PHP 8.1 builds turn out to be good, I'd also like to do
> the PHP 8.0 builds this way; this would free required capacities on the
> current build machine (plus save a bit of my time), which is actually
> supposed to do the PECL extension builds.


Automating PHP 8.0 builds sounds good as well.


> While these builds are
> automated, and mostly work well, there are sometimes issues with new
> releases and the dependency libraries are rarely updated (a lot of
> these[2] are ancient versions).  And although I'm planning to enable
> snapshot builds when PHP 8.1 enters the beta release cycle (as usual),
> and to do the mass rebuild after PHP 8.1.0 is released, I won't be able
> to spend much time to help with resolving issues.  In my opinion, it
> would be beneficial to push the burden of providing Windows builds to
> the extension maintainers.  There are already AppVeyor integrations for
> several PECL extensions, some of them producing binaries which are
> basically identical to the PECL builds, and generally Windows CI should
> be helpful for package maintainers to detect potential issues before new
> releases.  Furthermore, extensions maintainers would be more flexible
> regarding the supported PHP version (currently, the PECL builds are done
> for PHP 7.3, 7.4 and 8.0 only).
>

I see some possible complications here, mainly around storage and
accessibility of the produced artifacts. Artifacts produced by AppVeyor are
only stored for one month and not easily found. A nice thing about the
current system is that the artifacts for all extensions can be found in one
central place.

The minimum would be to move artifacts from AppVeyor into GitHub release
artifacts to make sure they're persistent, which is rather tedious without
some automation (there are >16 Windows release artifacts for apcu).

Regarding dependencies, does this mean that extensions should also build
DLLs for dependency libraries themselves? Are there any concerns about
different extensions building different versions of the same library, or
similar?

Regards,
Nikita

--0000000000002b2fdb05c4287776--