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
>
>

Reply via email to