# Adding a way to retreive compile options at runtime

- Thread: https://externals.io/message/66942
- Original archive: https://news-web.php.net/php.internals/66942
- Started by Julien Pauli on 2013-04-04T14:18:15+00:00
- Messages: 12
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #66942 — Julien Pauli — 2013-04-04T14:18:15+00:00

URL: https://externals.io/message/66942#66942

Hello everybody,

Today we talked about a way to detect --with-curlwrappers at runtime.
It is nowadays not possible easilly.

Then , I remembered I once proposed to add a new function that could return
every ./configure options used to compile the runtime PHP the code is
beeing run on.

We already have "php-config --configure-options", but that needs to exist
and that needs an `exec()` call.
We also already have `phpinfo()` which returns that, but not in a very fancy
way (we need to preg_ the output which is ugly and not very simple).

Today, Seldaek proposed what I think is a cool way to solve this problem :
add a new parameter to `phpinfo()` function, which could return in an array
what it usually directly print throught the SAPI print() function (HTMLing
the output when needed).

The use case would be :

<?php
$output = phpinfo(INFO_GENERAL, true);

var_dump($output);
/* something like
['Debug Build' =>'no', 'Thread Safety'=>'yes', 'Configure
Command'=>['--enable-foo', '--with-config-file-scan-dir'=>'/etc'
]]


As you can see, it is rather simple but would need some work as it is
better for the "Configure Command" to return an array with the options
instead of a big string ; easier to parse.

Thoughts ?

Julien.Pauli

---

## #66943 — Madara Uchiha — 2013-04-04T14:24:25+00:00

URL: https://externals.io/message/66942#66943 · In reply to: #66942

I'm having a hard time seeing production use cases for this.

While it is a very good suggestion, and probably not too hard to implement,
what benefit does it help you in an actual application outside the
development stage?

I'm in favor though, would probably have some uses during the development
stage.


> Hello everybody,
>
> Today we talked about a way to detect --with-curlwrappers at runtime.
> It is nowadays not possible easilly.
>
> Then , I remembered I once proposed to add a new function that could return
> every ./configure options used to compile the runtime PHP the code is
> beeing run on.
>
> We already have "php-config --configure-options", but that needs to exist
> and that needs an `exec()` call.
> We also already have `phpinfo()` which returns that, but not in a very fancy
> way (we need to preg_ the output which is ugly and not very simple).
>
> Today, Seldaek proposed what I think is a cool way to solve this problem :
> add a new parameter to `phpinfo()` function, which could return in an array
> what it usually directly print throught the SAPI print() function (HTMLing
> the output when needed).
>
> The use case would be :
>
> <?php
> $output = phpinfo(INFO_GENERAL, true);
>
> var_dump($output);
> /* something like
> ['Debug Build' =>'no', 'Thread Safety'=>'yes', 'Configure
> Command'=>['--enable-foo', '--with-config-file-scan-dir'=>'/etc'
> ]]
>
>
> As you can see, it is rather simple but would need some work as it is
> better for the "Configure Command" to return an array with the options
> instead of a big string ; easier to parse.
>
> Thoughts ?
>
> Julien.Pauli

---

## #66944 — johannes@schlueters.de — 2013-04-04T14:29:37+00:00

URL: https://externals.io/message/66942#66944 · In reply to: #66942

> 
> Then , I remembered I once proposed to add a new function that could
> return
> every ./configure options used to compile the runtime PHP the code is
> beeing run on.
> 
What's the purpose of this? What problems should be solved by that? - We
should have proper "reflection" on all things affecting the behavior,
but mind: Many things which can be done in configure could also be done
by loading shared extensions compiled independently, and things done in
the configure line might only affect extensions which were built shared
but not loaded ...

johannes

---

## #66945 — Leigh — 2013-04-04T14:29:38+00:00

URL: https://externals.io/message/66942#66945 · In reply to: #66942

I think creating easy processable output from `phpinfo()` is a good idea in
theory, but as Madara says, I'm also not sure about any other production
uses for this aside from the issue at hand with curlwrappers.

Are there many use cases except for the config options that this would be
useful for?

If not maybe a simpler php_configure_options() would be better, returning
an array as you proposed in your example.

Although I'm not sure about the returned format, in some cases the option
is a key, and in others it's a value.

I think options that do not take a value would be better represented as:
'--enable-foo' => true








> Hello everybody,
>
> Today we talked about a way to detect --with-curlwrappers at runtime.
> It is nowadays not possible easilly.
>
> Then , I remembered I once proposed to add a new function that could return
> every ./configure options used to compile the runtime PHP the code is
> beeing run on.
>
> We already have "php-config --configure-options", but that needs to exist
> and that needs an `exec()` call.
> We also already have `phpinfo()` which returns that, but not in a very fancy
> way (we need to preg_ the output which is ugly and not very simple).
>
> Today, Seldaek proposed what I think is a cool way to solve this problem :
> add a new parameter to `phpinfo()` function, which could return in an array
> what it usually directly print throught the SAPI print() function (HTMLing
> the output when needed).
>
> The use case would be :
>
> <?php
> $output = phpinfo(INFO_GENERAL, true);
>
> var_dump($output);
> /* something like
> ['Debug Build' =>'no', 'Thread Safety'=>'yes', 'Configure
> Command'=>['--enable-foo', '--with-config-file-scan-dir'=>'/etc'
> ]]
>
>
> As you can see, it is rather simple but would need some work as it is
> better for the "Configure Command" to return an array with the options
> instead of a big string ; easier to parse.
>
> Thoughts ?
>
> Julien.Pauli

---

## #66949 — Kalle Sommer Nielsen — 2013-04-04T15:51:25+00:00

URL: https://externals.io/message/66942#66949 · In reply to: #66942

Hi

2013/4/4 Julien Pauli <jpauli@php.net>:
> As you can see, it is rather simple but would need some work as it is
> better for the "Configure Command" to return an array with the options
> instead of a big string ; easier to parse.
>
> Thoughts ?

As Johannes already said, we got Reflection, and we should stick to
that, having the configure command is nice yeah, but its a mere of
edge cases that needs to parse this to correctly function because they
are doing something thats unusual in a general purpose environment you
have no control over.

Moreover, this will not work for shared extensions, imagine PECL
extensions for Windows for example.



-- 
regards,

Kalle Sommer Nielsen
kalle@php.net

---

## #66950 — Joe Watkins — 2013-04-04T16:05:46+00:00

URL: https://externals.io/message/66942#66950 · In reply to: #66942

> Hello everybody,
>
> Today we talked about a way to detect --with-curlwrappers at runtime.
> It is nowadays not possible easilly.
>
> Then , I remembered I once proposed to add a new function that could return
> every ./configure options used to compile the runtime PHP the code is
> beeing run on.
>
> We already have "php-config --configure-options", but that needs to exist
> and that needs an `exec()` call.
> We also already have `phpinfo()` which returns that, but not in a very fancy
> way (we need to preg_ the output which is ugly and not very simple).
>
> Today, Seldaek proposed what I think is a cool way to solve this problem :
> add a new parameter to `phpinfo()` function, which could return in an array
> what it usually directly print throught the SAPI print() function (HTMLing
> the output when needed).
>
> The use case would be :
>
> <?php
> $output = phpinfo(INFO_GENERAL, true);
>
> var_dump($output);
> /* something like
> ['Debug Build' =>'no', 'Thread Safety'=>'yes', 'Configure
> Command'=>['--enable-foo', '--with-config-file-scan-dir'=>'/etc'
> ]]
>
>
> As you can see, it is rather simple but would need some work as it is
> better for the "Configure Command" to return an array with the options
> instead of a big string ; easier to parse.
>
> Thoughts ?
>
> Julien.Pauli
>

Seems like a good idea to me ...

So ... https://gist.github.com/krakjoe/5311608

Array
(
     [with-apxs2] => /opt/php-nts/bin/apxs
     [prefix] => /opt/php-nts
     [exec-prefix] => /opt/php-nts
     [with-config-file-path] => /opt/php-nts/
     [with-config-file-scan-dir] => /opt/php-nts/modules.d/
     [with-curl] => /usr
     [with-zlib] => 1
     [with-libxml-dir] => /usr
     [enable-simplexml] => 1
     [with-mysql] => mysqlnd
     [with-pdo-mysql] => mysqlnd
     [enable-gd-native-ttf] => 1
     [with-mysqli] => 1
     [enable-sockets] => 1
     [with-gd] => 1
     [enable-debug] => 1
)

Something that hasn't been mentioned, installation of software like 
wordpress or whatever, might be able to offer advice to the end user 
based on the configuration defaults, regardless of ini settings.

Joe

---

## #66952 — johannes@schlueters.de — 2013-04-04T16:53:10+00:00

URL: https://externals.io/message/66942#66952 · In reply to: #66950

Joe Watkins <krakjoe@php.net> wrote:

>Something that hasn't been mentioned, installation of software like 
>wordpress or whatever, might be able to offer advice to the end user 
>based on the configuration defaults, regardless of ini settings.

Le me repeat what I said in this thread using other words:

No, it can't. In a typical case (PHP from distribution with "all" extensions shared) this has *no* relevance regarding the running system. The extensions loaded might be built completely different from what's said there.

Provide the information needed by constants or function calls from an extenson or whatever makes sense, don't advocate to do the wrong thing.

johannes

---

## #66954 — Joe Watkins — 2013-04-04T17:09:47+00:00

URL: https://externals.io/message/66942#66954 · In reply to: #66952

>
>
> Joe Watkins <krakjoe@php.net> wrote:
>
> > […]
>
> Le me repeat what I said in this thread using other words:
>
> No, it can't. In a typical case (PHP from distribution with "all" extensions shared) this has *no* relevance regarding the running system. The extensions loaded might be built completely different from what's said there.
>
> Provide the information needed by constants or function calls from an extenson or whatever makes sense, don't advocate to do the wrong thing.
>
> johannes
>

Many extensions do not provide constants or functions to detect the way 
they are configured, this may or may not expose those options, which is 
better than not being able to expose those options by any reasonable means.

More importantly, it does not only contain information about extensions, 
or which extensions are loaded and how ( I am aware of the problems of 
using this kind of information as authoritative, I still say something 
is better than nothing, see every 404 page in all modern browsers, why 
not provide suggestions, even if they are wrong ).

Path information I figure could be useful while setting up software, so 
could many other configure time options, for example if more than one 
SAPI was built at configure time, you might advise the use of the most 
suitable SAPI for your software, you might generate an ini file and tell 
the user where to put it (scandir), you might have the abnormal path to 
php-config or other things distributed with php and installed in a 
non-standard path (/opt/php-nts in example output).

There's a bunch of useful stuff in the configure command ... not just 
extensions loaded ...

---

## #66955 — johannes@schlueters.de — 2013-04-04T17:30:55+00:00

URL: https://externals.io/message/66942#66955 · In reply to: #66954

Joe Watkins <krakjoe@php.net> wrote:

>Many extensions do not provide constants or functions to detect the way
>they are configured, this may or may not expose those options, which is
>better than not being able to expose those options by any reasonable
>means.

Then those extensions should expose the required information. These are bugs then.

>More importantly, it does not only contain information about
>extensions, 
>or which extensions are loaded and how ( I am aware of the problems of 
>using this kind of information as authoritative, I still say something 
>is better than nothing, see every 404 page in all modern browsers, why 
>not provide suggestions, even if they are wrong ).
>
>Path information I figure could be useful while setting up software, so

The paths set during configure time don't have to match those where things are installed. Especially admins might prefer to use symlinked paths for configuration and users might be misled.

>could many other configure time options, for example if more than one 
>SAPI was built at configure time, you might advise the use of the most 
>suitable SAPI for your software,

SAPIs might be built individually. Having them enabled during configure time doesn't mean they are enabled or accessible by the user.

> you might generate an ini file and
>tell 
>the user where to put it (scandir), you might have the abnormal path to
>php-config or other things distributed with php and installed in a 
>non-standard path (/opt/php-nts in example output).

configure options often won't tell-

>There's a bunch of useful stuff in the configure command ... not just 
>extensions loaded ...

Yes and a lot of wrong information.

johannes

---

## #66956 — Joe Watkins — 2013-04-04T17:40:11+00:00

URL: https://externals.io/message/66942#66956 · In reply to: #66955

>
>
> Joe Watkins <krakjoe@php.net> wrote:
>
> > […]
>
> Then those extensions should expose the required information. These are bugs then.
>
> > […]
>
> The paths set during configure time don't have to match those where things are installed. Especially admins might prefer to use symlinked paths for configuration and users might be misled.
>
> > […]
>
> SAPIs might be built individually. Having them enabled during configure time doesn't mean they are enabled or accessible by the user.
>
> > […]
>
> configure options often won't tell-
>
> > […]
>
> Yes and a lot of wrong information.
>
> johannes
>

A combination of ENV, ini, phpversion and phpconfopt options should 
allow you to make much more informed decisions or do nothing at all, 
there is not a reasonable means to acquire this information, nor is it 
reasonable to suggest that we modify every single bundled extension in 
order to expose their configuration options, additional constants and 
maybe add new functions/methods.

I keep using the words could, might, maybe, *on purpose*, I am aware 
that the configuration time options may not match runtime parameters, I 
don't think it falls to us to provide the business logic, so it doesn't 
really matter that the setup may be completely different, it may be the 
same, or similar. It may be vital information, it may also be completely 
irrelevant, exposing it provides more flexibility than doing nothing at all.

Joe

---

## #66958 — Kris Craig — 2013-04-04T18:04:51+00:00

URL: https://externals.io/message/66942#66958 · In reply to: #66956

> 
>
> > […]
> A combination of ENV, ini, phpversion and phpconfopt options should allow
> you to make much more informed decisions or do nothing at all, there is not
> a reasonable means to acquire this information, nor is it reasonable to
> suggest that we modify every single bundled extension in order to expose
> their configuration options, additional constants and maybe add new
> functions/methods.
>
> I keep using the words could, might, maybe, *on purpose*, I am aware that
> the configuration time options may not match runtime parameters, I don't
> think it falls to us to provide the business logic, so it doesn't really
> matter that the setup may be completely different, it may be the same, or
> similar. It may be vital information, it may also be completely irrelevant,
> exposing it provides more flexibility than doing nothing at all.
>
> Joe
>
>
>
>
> --
> 
> 
>
>
I don't see any useful production applications for this.  However, I could
say the same thing about `phpinfo()` itself.  From a debugging and QA
standpoint, on the other hand, this could be potentially useful.  If, for
example, I was writing some sort of server analysis or troubleshooting
utility, it might be helpful for me to be able to grab the configure
command (or anything else in `phpinfo()`, for that matter) without having to
do a screen scape.

So even though the use case for this is somewhat narrow, I think it's
something we should have in place, anyway.  You should definitely write an
RFC for this.

--Kris

---

## #66962 — Julien Pauli — 2013-04-04T20:59:04+00:00

URL: https://externals.io/message/66942#66962

The main use case was the topic about --with-curlwrappers from Laruence few
days ago.

Actually, for this use case , there is no way to detect if PHP's been
compiled with --with-curlwrappers or not.
The only way to detect this at runtime is to open a socket, then
stream_get_metadata() onto it.

Some code in the well-known "Composer" project, from Seldaek, uses ugly
hacks, see
https://github.com/composer/getcomposer.org/blob/master/web/installer#L135-148
Same for --enable-sigchild , the use case is here :
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Process/Process.php#L1061

After some reflection, we could find other ./configure options which cant
be detected at runtime without parsing the `phpinfo()` output.
For example, one may need to know if --enable-zend-signals h'as been
enabled or not, for playing, say, with ext/pcntl

I can write an RFC about this if needed, just wanted to get some thoughts
before :-)

Julien.Pauli




> 
>
> > […]
> I can't think of anywhere it's definitely useful, but I can think of many
> places it might be, combined with the right logic, and other things from
> environment/runtime/info etc ...
>
> There's probably one or two server analysis tools in production out there
> :)
>
> Hopefully, jpauli is still okay to move forward with an RFC, if the
> implementation is any good ...
>
> Writing bits of code, good fun, these long drawn out conversations and
> those that are the result of RFC creation ... not so much ...
>
>
> Joe