Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24260
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <44A9AECD.2090200@lerdorf.com>
References: <952E8F04-87DB-4925-8F08-B999DE354D65@skytag.com> <44A9B7AD.502@developersdesk.com> <3A0FCD44-B118-48B2-AD9C-8055EFA0AE91@skytag.com> <44A9AECD.2090200@lerdorf.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <502942BF-7E4C-45B7-9C25-F6D04A3B7E03@skytag.com>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Mon, 3 Jul 2006 21:12:17 -0400
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Subject: Re: [PHP-DEV] Configure summary
From: gwynne@skytag.com (Gwynne)

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?

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."