Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66962
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.52 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <515DC7E5.9030301@php.net>
References: <CAMUwpuTUOx6o8bYyiEJ1qmRdgGfR18=MR8Y+n-ubB3OqVo_orw@mail.gmail.com>
 <515DA4DA.2060300@php.net> <1921fdc8-6aa8-4377-adca-38368386676c@email.android.com>
 <CF.77.35962.FD3BD515@pb1.pair.com> <2c75b559-d8bd-42a0-aafe-11b770e16c1f@email.android.com>
 <515DBAFB.1020000@php.net> <CAKOpQSwvSb++nvOBB0ysuQXTkU4UV0AGFpQ7Couy+z7LrsiGfw@mail.gmail.com>
 <515DC7E5.9030301@php.net>
Date: Thu, 4 Apr 2013 22:59:04 +0200
Message-ID: <CAMUwpuTehsuJgdzdGCYp-aR8j+wJZ1r7aK8cvVAc4pnvm__TRw@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP Internals <internals@lists.php.net>, Kris Craig <kris.craig@gmail.com>
Content-Type: multipart/alternative; boundary=20cf307f34640effb104d98f4069
Subject: Re: [PHP-DEV] Re: Adding a way to retreive compile options at runtime
From: jpauli@php.net (Julien Pauli)

--20cf307f34640effb104d98f4069
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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/Proces=
s/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 <krakjoe@php.net> wrote:

> On 04/04/2013 07:04 PM, Kris Craig wrote:
>
>> On Thu, Apr 4, 2013 at 10:40 AM, Joe Watkins <krakjoe@php.net> wrote:
>>
>>  On 04/04/2013 06:30 PM, Johannes Schl=FCter wrote:
>>>
>>>
>>>>
>>>> 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 ar=
e
>>>> 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 o=
f
>>>>> using this kind of information as authoritative, I still say somethin=
g
>>>>> is better than nothing, see every 404 page in all modern browsers, wh=
y
>>>>> 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 on=
e
>>>>
>>>>> SAPI was built at configure time, you might advise the use of the mos=
t
>>>>> suitable SAPI for your software,
>>>>>
>>>>>
>>>> SAPIs might be built individually. Having them enabled during configur=
e
>>>> 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 jus=
t
>>>>
>>>>> 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 expos=
e
>>> their configuration options, additional constants and maybe add new
>>> functions/methods.
>>>
>>> I keep using the words could, might, maybe, *on purpose*, I am aware th=
at
>>> 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 reall=
y
>>> 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, fo=
r
>> 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
>
>

--20cf307f34640effb104d98f4069--