Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZTS support #695

Open
dzuelke opened this issue Feb 9, 2024 · 0 comments
Open

ZTS support #695

dzuelke opened this issue Feb 9, 2024 · 0 comments
Assignees

Comments

@dzuelke
Copy link
Contributor

dzuelke commented Feb 9, 2024

This issue is for collecting notes and ideas around supporting PHP builds that have Zend Thread Safety ("ZTS") enabled, in addition to regular ("NTS") builds.

There have been (implicit) requests over the years for ZTS builds, mostly to support extensions that need it (e.g. #693), but there are other use cases, such as for embedding PHP (#675).

The main challenge is that we'll want ZTS and NTS builds of PHP and extensions to co-exist inside the same platform package repository, so that the suitable variant automatically gets selected. This means a php-8.3.2 package will result in two built versions, each with their respective provide and conflict entries for php-zts, and all extensions need the same (with require and conflict entries for php-zts).

In that case, though, it becomes a bit of a guessing game what the solver will ultimately pick in case there is no requirement for something that needs ZTS, and we definitely want to default to NTS.

The more naive solution is to have users that need ZTS put an explicit php-zts requirement into their root composer.json, but that's not very elegant.

Maybe something can be tricked using a prefer-nts virtual package that all NTS builds provide (or require) in version 1, and all ZTS builds provide (or require) in version 0, and it always gets required at the root using a * constraint (unsure if pure provides will work, the solver might not take the "highest version possible" rules into account anymore at that stage, but an actual fake metapackage in the repo would probably work).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant