Hi, > -----Original Message----- > From: Nikita Popov <nikita....@gmail.com> > Sent: Monday, June 7, 2021 1:07 PM > To: Christoph M. Becker <cmbecke...@gmx.de> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows > > On Mon, Jun 7, 2021 at 10:58 AM Christoph M. Becker > <cmbecke...@gmx.de> > wrote: > > > On 07.06.2021 at 10:02, Nikita Popov wrote: > > > > > On Sun, Jun 6, 2021 at 3:26 PM Christoph M. Becker > <cmbecke...@gmx.de> > > > wrote: > > > > >> 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. > > > > Right, that is about building the relese artifacts, which will then be > > available from <https://windows.php.net/>. > > > > >> 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? > > > > Indeed, Microsoft has no intentions to maintain that repo for PHP 8, so > > we need to fork. > > > > Okay, sounds good to me. Rather than a GitHub fork, I'd suggest pushing a > clone of the repo, and indicate the original source in the repo > description. GitHub forks have some annoying limitations (like the > inability to use search), which are not great for long-term forks. > > > > >> 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). > > > > AppVeyor (and other CI providers) allows to upload artifacts to > > arbitrary locations; at least AppVeyor supports uploading of artifacts > > to GH realeases[1], so this could be automated. I'd be very surprised, > > if other GH CI providers wouldn't support that as well. > > > > [1] <https://www.appveyor.com/docs/deployment/github/> > > > > Okay, that looks nice, and should make producing Windows builds a matter > of > creating a GitHub tag. Do you know if any PHP ext already uses this, so it > could be seen in action? > > > 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? > > > > Oh, right, that could be an issue. Maybe we should stick with providing > > the dependencies from windows.php.net? Not sure how to handle the > > details, though. This doesn't look super urgent to me, but I would like > > to see more (Windows) CI integrations of the package repos soon. > > Reusable, publicly available GH actions might make CI integration for > > packages super simple even on Windows. Any help welcome! > > > > Right. I think a problem here is that the AppVeyor configuration for > extensions is a bit arcane (at least to me). If one could just pick up a > centrally maintained action from the GH marketplace, put in your target PHP > versions and let the magic happen, that would make things simpler. >
Thanks, Christoph, for managing the Windows builds nicely so far! 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. Thanks anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
