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 On Thu, Apr 4, 2013 at 8:35 PM, Joe Watkins <krak...@php.net> wrote: > On 04/04/2013 07:04 PM, Kris Craig wrote: > >> On Thu, Apr 4, 2013 at 10:40 AM, Joe Watkins <krak...@php.net> wrote: >> >> On 04/04/2013 06:30 PM, Johannes Schlüter wrote: >>> >>> >>>> >>>> Joe Watkins <krak...@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 >>>> >>>> >>>> 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 >>> >>> >>> >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >>> 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 >> >> > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
