On Wed, Nov 11, 2020 at 10:27:33PM +0000, Olly Betts
wrote:> On Wed, Nov 11, 2020 at 09:23:23AM -0500, Jim wrote:
> > Apparently there is a php 7.4 configuration missing.? This is bindings
> > 1.4.17 running on a Mint 20 system.
> >
> > I see this in the config output:
> >
> > cpython-38.opt-1.pyc
> > checking for php-config7.3... no
> > checking for php-config7.2... no
> > checking for php-config7.1... no
> > checking for php-config7.0... no
> > checking for php-config... no
> >
> > It didn't look for 7.4.
>
> Thanks, I'll add the missing entry.
I started to do this, but started thinking that having to maintain a
list of versions to check seemed a problematic approach. It requires
maintenance and means old releases don't know about new PHP7 releases,
and worse will prefer older PHP7 releases they know about if multiple
are installed.
Looking at the history of this, it looks like the reason for doing this
is probably that, in the early days of PHP7, php-config would usually
still be for PHP5 and so looking for php-config7.1, etc was necessary to
find a php-config for PHP7 automatically.
I'd expect that nowadays php-config will be for PHP7 not PHP5, and at
least on Debian derived systems php-config will be for the preferred
PHP 7.x (as selected via the alternatives system) if multiple are
installed. Our current approach means we ignore that preference and
installed build for the newest PHP that we know about for which the
corresponding php7.X-dev is installed. This all seems to argue for
reducing this list to just look for php-config. If the user really
wants to build for a different PHP7 install they can point to it via
PHP_CONFIG7, e.g.:
> ./configure PHP_CONFIG7=php-config7.4
The PHP upstream versions seems to install php-config, and a quick look
at some other commonly used Linux distros suggested that they package
this as php-config.
The other approach to avoid the problems of manually keeping a list
that I can see is to do have a loop (say on "x") for some number above
any feasible minor version down to 0 and check for php-config7.$x -
that's a lot of redundant checking though. It's not really feasible
to do a wildcard match as we need to search PATH at the same time.
Thoughts?
We could also change to only look for php-config for the next release
series, but keep the current approach in 1.4.x (and update the list
of known versions).
> AIUI Linux Mint is based on Ubuntu or Debian (depending on edition) and
> there you should get a /usr/bin/php-config (via the alternatives system)
> if you have any php -dev package installed, and your configure output
> shows php-config as not found.
>
> If Linux Mint lacks the php-config alternative for some reason, the last
> part points you to how to workaround the omission of 7.4 from that list:
It would be useful to confirm if Linux Mint has an unversioned php-config
if a suitable php7.X-dev package is installed, or it deviates from
Debian/Ubuntu in this regard. If it really doesn't, that's an
argument against only looking for php-config.
Cheers,
Olly