[PHP-DEV] Adding a way to retreive compile options at runtime
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
Re: [PHP-DEV] Adding a way to retreive compile options at runtime
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. On Apr 4, 2013 5:19 PM, Julien Pauli jpa...@php.net wrote: 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
Re: [PHP-DEV] Adding a way to retreive compile options at runtime
On Thu, 2013-04-04 at 16:18 +0200, Julien Pauli wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a way to retreive compile options at runtime
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 On 4 April 2013 15:18, Julien Pauli jpa...@php.net wrote: 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
Re: [PHP-DEV] Adding a way to retreive compile options at runtime
Hi 2013/4/4 Julien Pauli jpa...@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
