Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24261
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <44A9C172.3080103@lerdorf.com>
Date: Mon, 03 Jul 2006 18:16:34 -0700
User-Agent: Thunderbird 3.0a1 (Macintosh/20060622)
MIME-Version: 1.0
To: Gwynne <gwynne@skytag.com>
CC: internals@lists.php.net
References: <952E8F04-87DB-4925-8F08-B999DE354D65@skytag.com> <44A9B7AD.502@developersdesk.com> <3A0FCD44-B118-48B2-AD9C-8055EFA0AE91@skytag.com> <44A9AECD.2090200@lerdorf.com> <502942BF-7E4C-45B7-9C25-F6D04A3B7E03@skytag.com>
In-Reply-To: <502942BF-7E4C-45B7-9C25-F6D04A3B7E03@skytag.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Configure summary
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Gwynne wrote:
> On Jul 3, 2006, at 7:57 PM, Rasmus Lerdorf wrote:
>>> The general consensus seems to be that I should show as much info as 
>>> is reasonably possible. For this, extensions need to be able to 
>>> register the summary information they can provide. I've come up with 
>>> a couple of different ideas for the syntax on this:
>>> 1) Add a new parameter to PHP_NEW_EXTENSION(), i.e.:
>>>     PHP_NEW_EXTENSION(standard, array.c base64.c basic_functions.c 
>>> browscap.c crc32.c # \ etc,
>>>                        ,,,, \
>>>                        [Standard functions
>>> Regex type:--with-regex=${REGEX_TYPE}])
>>> 2) AC_DEFUN() a new macro, i.e.:
>>>     PHP_SUMMARY_INFO([Standard functions], [Extension: Enabled
>>> Regex type: --with-regex=${REGEX_TYPE}])
>>> These are just random examples based on the standard extension, 
>>> obviously. Anyone like either of these or have a better idea?
>> I really don't think it is worth changing/adding to the extension API 
>> for this in any way.
>>
>> If we can't do a simple summary with what we already have, let's just 
>> skip it.  And as far as I am concerned, showing as much as possible 
>> isn't the goal here.  The goal for me would be to get a summary that 
>> fits on a single 80x25 page without scrolling.  If it is so long that 
>> it scrolls off, then we haven't gained much.  It should be a 
>> quick-summary that you can glance at and quickly pick out if 
>> everything looks ok.
> 
> That was my original intention, but I was shouted down twice already 
> when I suggested it. I'm willing to implement both options, maybe put 
> the one that changes the extension API in HEAD only?

I still don't think we need to make the extension API any more complex. 
  We already have an extension summary in the config.m4 file and it 
should be possible to fiddle with the autoconf macros to pull it from 
there.  Forcing people to write this stuff twice doesn't make much sense.

Go with your initial instict and do a nice short and concise summary.  I 
see no reason for a phpinfo() like thing since you can just type 
sapi/cli/php -i to get that.

-Rasmus