Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66958
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <515DBAFB.1020000@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>
Date: Thu, 4 Apr 2013 11:04:51 -0700
Message-ID: <CAKOpQSwvSb++nvOBB0ysuQXTkU4UV0AGFpQ7Couy+z7LrsiGfw@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: internals@lists.php.net, =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Content-Type: multipart/alternative; boundary=047d7bb04d7e9d0a5c04d98cce56
Subject: Re: [PHP-DEV] Re: Adding a way to retreive compile options at runtime
From: kris.craig@gmail.com (Kris Craig)

--047d7bb04d7e9d0a5c04d98cce56
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 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 pa=
ths
>> 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 n=
ot
> 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 irrelevan=
t,
> 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

--047d7bb04d7e9d0a5c04d98cce56--