You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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 respectiveprovide
andconflict
entries forphp-zts
, and all extensions need the same (withrequire
andconflict
entries forphp-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 rootcomposer.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 fakemetapackage
in the repo would probably work).The text was updated successfully, but these errors were encountered: