Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95563
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <3818ee78-9795-ce5e-6a0a-703e45cd904a@heigl.org>
References: <CA+nBocAnsa5Gp21iECviQfeU_8pJXpsXVAaWGVuzS5_PZjsOuA@mail.gmail.com>
 <3818ee78-9795-ce5e-6a0a-703e45cd904a@heigl.org>
Date: Fri, 2 Sep 2016 16:49:38 +0300
Message-ID: <CA+nBocDSknOe4XUfhTXhFAPJgJ1a97146LZzPNOGXef7ug4szg@mail.gmail.com>
To: Andreas Heigl <andreas@heigl.org>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=94eb2c14fe1e30acbe053b869b55
Subject: Re: [PHP-DEV] Non-conflicting PHP 5 and 7 builds
From: coladict@gmail.com (Jordan Gigov)

--94eb2c14fe1e30acbe053b869b55
Content-Type: text/plain; charset=UTF-8

I'll try to answer as best I can.

> Is it possible to extend that system also to minor and patch versions?
Extending it to allow minor versions would require some changes in
"scripts/phpize.m4" and "scripts/phpize.in" to make that information
available to extensions, without having to parse the version string.
It would probably be better to make them maintain information about
"--program-prefix" and "--program-suffix", which would also need to be
added to the "phpincludedir" variable.
phpincludedir is maintained in four locations in "scripts/Makefile.frag",
"ext/pdo/Makefile.frag", "scripts/php-config.in" and "scripts/phpize.in".
That should really be unified to one variable some day.
Using "--program-prefix" and "--program-suffix" would then ensure no
conflict ever arises if say, you want to change something in the installed
headers and you don't feel safe about overwriting them for the major
version.

> What effect has that on docker or vagrant systems? Especially on
maintainability of up-to-date versions that will have to symlink the
current version to a new binary with every version?
I don't know what docker/vagrant container set-up you have in mind, but
generally if the system has "update-alternatives", you will be able to use
it to switch all of the symlinks from the default paths to point to the
particular build. If it doesn't, so long as you keep that Makefile intact
you can use "make install-alternatives" to overwrite all the symlinks.
There are no provided symlink alternatives for an Apache module, nor an FPM
unix socket, as there isn't a default one defined or recommended.

> what effect would that have on non-release versions?
The "install-alternatives" target would have to be added last to the
defaults to ensure backwards compatibility for unsuspecting builders.
Currently it is not, and must be specified when calling "make".

2016-09-02 15:47 GMT+03:00 Andreas Heigl <andreas@heigl.org>:

> Hi Jordan.
>
> Great Idea.
>
> There are just a few questions I have:
>
> * Is it possible to extend that system also to minor and patch versions?
> * What effect has that on docker or vagrant systems? Especially on
> maintainability of up-to-date versions that will have to symlink the
> current version to a new binary with every version?
> * what effect would that have on non-release versions?
>
> For our development it has been intresting to be able to switch between
> different minor and patch-versions of PHP so we use vagrant or docker
> for different projects depending on the PHP-Version available on the
> productive servers. That can then also include extensions and so on.
>
> Alternatively I've used the prefix to distinguish between the versions
> and then created symlinks to the binaries inside a bin-folder. When that
> was necessary at all, as f.e. php-fpm can be called right inside the
> respective prefiexed folder...
>
> And then there's also phpenv which took rbenv as a model.
>
> Cheers
>
> Andreas
>
>

--94eb2c14fe1e30acbe053b869b55--