# Configure summary

- Thread: https://externals.io/message/24247
- Original archive: https://news-web.php.net/php.internals/24247
- Started by Gwynne on 2006-07-03T15:35:52+00:00
- Messages: 20
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #24247 — Gwynne — 2006-07-03T15:35:52+00:00

URL: https://externals.io/message/24247#24247

I was poking around at the TODO and I saw this:

     * make configure print out a summary when it's done (like XEmacs)

I'm working on a patch to bring in this functionality, out of sheer  
"I need to learn more about autoconf and I want to contribute to PHP"- 
ness :). Does anyone have any thoughts on what might go into such a  
summary? So far, I have install prefix, SAPI, debug on/off, things of  
that simple nature. Also, any thoughts on whether the summary should  
be printed from configure itself or config.status?

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

---

## #24251 — Richard Lynch — 2006-07-03T19:27:50+00:00

URL: https://externals.io/message/24247#24251 · In reply to: #24247

> I was poking around at the TODO and I saw this:
>
>      * make configure print out a summary when it's done (like XEmacs)
>
> I'm working on a patch to bring in this functionality, out of sheer
> "I need to learn more about autoconf and I want to contribute to PHP"-
> ness :). Does anyone have any thoughts on what might go into such a
> summary? So far, I have install prefix, SAPI, debug on/off, things of
> that simple nature. Also, any thoughts on whether the summary should
> be printed from configure itself or config.status?

My personal heretical naive opinion is that a configure summary should
print out pretty much the same thing I would get if I did `phpinfo()` in
the make that resulted from this build, and the more similar to that
you can get, the better.

Since 'make' now builds multiple SAPIs at once (e.g. apxs + CLI + CGI)
that part should be different, though.

YMMV

-- 
Like Music?
http://l-i-e.com/artists.htm

---

## #24252 — Derick Rethans — 2006-07-03T20:35:08+00:00

URL: https://externals.io/message/24247#24252 · In reply to: #24251

> 
> > […]
> 
> My personal heretical naive opinion is that a configure summary should
> print out pretty much the same thing I would get if I did `phpinfo()` in
> the make that resulted from this build, and the more similar to that
> you can get, the better.
> 
> Since 'make' now builds multiple SAPIs at once (e.g. apxs + CLI + CGI)

It can't build three at once. Just CLI + another module.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #24253 — Gwynne — 2006-07-03T20:48:05+00:00

URL: https://externals.io/message/24247#24253 · In reply to: #24251

> > […]
> My personal heretical naive opinion is that a configure summary should
> print out pretty much the same thing I would get if I did `phpinfo()` in
> the make that resulted from this build, and the more similar to that
> you can get, the better.
>
> Since 'make' now builds multiple SAPIs at once (e.g. apxs + CLI + CGI)
> that part should be different, though.

 `phpinfo()` is rather... long... for a configure output, but the  
information I'm already providing in my initial revision of this  
patch pretty much covers the first section of it anyway.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

---

## #24254 — Pierre — 2006-07-03T22:09:49+00:00

URL: https://externals.io/message/24247#24254 · In reply to: #24247

Hi,



> I'm working on a patch to bring in this functionality, out of sheer
> "I need to learn more about autoconf and I want to contribute to PHP"-
> ness :). Does anyone have any thoughts on what might go into such a
> summary?

Something like:

GD Support Yes
  Bundled
  PNG Yes
  JPEG No
  GIF R/W Yes

PDO Support Yes
 PDO Mysql Yes
 PDO Sqlite Bundled Yes
...

Maybe with the version found and used, but it could make the summary
unreadable :)

> So far, I have install prefix, SAPI, debug on/off, things of
> that simple nature. Also, any thoughts on whether the summary should
> be printed from configure itself or config.status?

I think it may require some additional macros. These macros can be
called from the extension to set the key/value pairs to display.

Good luck and don't hesitate to harass the list until you get it
working, this is something I was waiting for since way too long (and
being lazy ;)

Cheers,
--Pierre

---

## #24255 — Gwynne — 2006-07-03T22:16:50+00:00

URL: https://externals.io/message/24247#24255 · In reply to: #24254

> > […]
> Something like:
>
> GD Support Yes
>  Bundled
>  PNG Yes
>  JPEG No
>  GIF R/W Yes
>
> PDO Support Yes
> PDO Mysql Yes
> PDO Sqlite Bundled Yes
> ...
>
> Maybe with the version found and used, but it could make the summary
> unreadable :)

The problem I have with this is that all of that information is  
already findable from the configure output. Yes, you have to look for  
it, but the idea of a summary is to summarize, not give extensive  
details and basically duplicate all the AC_MSG_CHECKING output. Maybe  
this is something that would only be provided by my --with- 
summary=extended switch?

> > […]
> I think it may require some additional macros. These macros can be
> called from the extension to set the key/value pairs to display.

I had this thought, but I wasn't really looking to do something  
that'd require changing every config.m4 file in the PHP hierarchy.  
Obviously this would be optional for any given extension, but still,  
it's a larger job than I'm fully confident I can do.

> Good luck and don't hesitate to harass the list until you get it
> working, this is something I was waiting for since way too long (and
> being lazy ;)

Well in that case, perhaps someone can tell me whether I should be  
displaying this information from configure itself (configure.in  
AC_MSG_RESULT macros) or from config.status (init_cmds in  
AC_OUTPUT) :). If it's available from config.status, maybe that'd be  
another reason to provide the very detailed output you suggested above?

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

---

## #24256 — Pierre — 2006-07-03T22:24:05+00:00

URL: https://externals.io/message/24247#24256 · In reply to: #24255

> 
> > […]
>
> The problem I have with this is that all of that information is
> already findable from the configure output. Yes, you have to look for
> it, but the idea of a summary is to summarize, not give extensive
> details and basically duplicate all the AC_MSG_CHECKING output.

The output of configure is useless unless you redirect it to a file
and check everything you are looking for. A summary of this form is
used is many project. There is no need to be very verbose, only saying
what is enabled is already enough.

> Maybe this is something that would only be provided by my --with-
> summary=extended switch?

It should be on by default. I don't count how many times I have had to
run configure again and again because I mis read the output or log :)

> I had this thought, but I wasn't really looking to do something
> that'd require changing every config.m4 file in the PHP hierarchy.
> Obviously this would be optional for any given extension, but still,
> it's a larger job than I'm fully confident I can do.

We already do it anyway with the configure line itself (--with-myext
or --enable-myext, or any other configure option), adding such thing
is a one shot job.

> Well in that case, perhaps someone can tell me whether I should be
> displaying this information from configure itself (configure.in
> AC_MSG_RESULT macros) or from config.status (init_cmds in
> AC_OUTPUT) :). If it's available from config.status, maybe that'd be
> another reason to provide the very detailed output you suggested above?

I have to check again these macros, but the summary is not very
detailed, it is really only a summary of the enabled features :)

--Pierre

---

## #24257 — Rasmus Lerdorf — 2006-07-03T22:53:23+00:00

URL: https://externals.io/message/24247#24257 · In reply to: #24256

Pierre wrote:
> 
> > […]
> 
> The output of configure is useless unless you redirect it to a file
> and check everything you are looking for. A summary of this form is
> used is many project. There is no need to be very verbose, only saying
> what is enabled is already enough.

I would agree with Pierre here.  A nice compact summary of what was 
actually found and where it was found would be what I would expect from 
this.

-Rasmus

---

## #24258 — Gwynne — 2006-07-03T23:51:49+00:00

URL: https://externals.io/message/24247#24258

> > […]
> I would say it should list every option that the user can select,  
> and show its value.  For extra credit, on each entry tell if the  
> value is the default - either set to the default value, or not  
> specified.

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?

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

---

## #24259 — Rasmus Lerdorf — 2006-07-03T23:57:01+00:00

URL: https://externals.io/message/24247#24259 · In reply to: #24258

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

-Rasmus

---

## #24260 — Gwynne — 2006-07-04T01:12:17+00:00

URL: https://externals.io/message/24247#24260 · In reply to: #24259

> > […]
> 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."

---

## #24261 — Rasmus Lerdorf — 2006-07-04T01:16:34+00:00

URL: https://externals.io/message/24247#24261 · In reply to: #24260

Gwynne wrote:
> 
> > […]
> 
> 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

---

## #24262 — Sebastian Bergmann — 2006-07-04T05:39:40+00:00

URL: https://externals.io/message/24247#24262 · In reply to: #24252

Derick Rethans wrote:
> It can't build three at once. Just CLI + another module.

 We have a patch for that in the PHP package for Gentoo Linux.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

---

## #24263 — Michael Wallner — 2006-07-04T07:47:27+00:00

URL: https://externals.io/message/24247#24263 · In reply to: #24262

Sebastian Bergmann wrote:
> Derick Rethans wrote:
> > […]
> 
>  We have a patch for that in the PHP package for Gentoo Linux.

That's interesting. What happens on `make install`? Does it 
have separate install commands per SAPI?

Thanks,
-- 
Michael

---

## #24264 — Sebastian Bergmann — 2006-07-04T08:22:09+00:00

URL: https://externals.io/message/24247#24264 · In reply to: #24263

Michael Wallner wrote:
> That's interesting. What happens on `make install`? Does it have
> separate install commands per SAPI?

 I will ask Luca, the maintainer of this patch.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

---

## #24267 — Luca Longinotti — 2006-07-04T14:29:15+00:00

URL: https://externals.io/message/24247#24267 · In reply to: #24264

Sebastian Bergmann wrote:
> Michael Wallner wrote:
> > […]
> 
>  I will ask Luca, the maintainer of this patch.

That would be me. :)
The patch basically adds CGI to the SAPIs that can be built in one go,
so we can build CLI, CGI and the Apache SAPIs all in one go.
The patch for PHP 4.4.2 can be found at
http://overlays.gentoo.org/proj/php/browser/patches/php-patches/4.4.2/opt/php4.4.2-fastbuild.patch
and the one for PHP 5.1.4 at
http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.1.4/opt/php5.1.4-fastbuild.patch
Once the patch is applied, just do something like:

./configure --prefix=/usr --sysconfdir=/etc --cache-file=./config.cache
--with-libdir=/usr/lib --with-pic --enable-cli --enable-cgi
--enable-fastcgi --with-apxs2=/usr/sbin/apxs2

make (will make all three SAPIs, you can also only do make sapi/cli/php
or make sapi/cgi/php)

make install-cli (will install the php binary)
make install-cgi (will install the php-cgi binary)
make install-sapi (will install the Apache module)
or
make install (to install all the install targets)
-- 
Best regards,
Luca Longinotti aka CHTEKK

LongiTEKK Networks Admin: chtekk@longitekk.com
Gentoo Dev: chtekk@gentoo.org
SysCP Dev: chtekk@syscp.org
TILUG Supporter: chtekk@tilug.ch

---

## #24273 — Michael Wallner — 2006-07-05T10:10:57+00:00

URL: https://externals.io/message/24247#24273 · In reply to: #24267

Luca Longinotti wrote:
> Sebastian Bergmann wrote:
> > […]

> > […]

> > […]

> The patch basically adds CGI to the SAPIs that can be built in one 
> go, so we can build CLI, CGI and the Apache SAPIs all in one go.

Ilia et al, anything against integrating this into 5_2?

Regards,
-- 
Michael

---

## #24274 — Gwynne — 2006-07-05T10:16:31+00:00

URL: https://externals.io/message/24247#24274 · In reply to: #24273

> > […]
> Ilia et al, anything against integrating this into 5_2?

I'm not Ilia or any of the others with control over the PHP process,  
but I want to throw in my vote in favor of this idea regardless :).

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

---

## #24289 — Richard Lynch — 2006-07-07T20:16:33+00:00

URL: https://externals.io/message/24247#24289 · In reply to: #24274

> 
> > […]
>
> I'm not Ilia or any of the others with control over the PHP process,
> but I want to throw in my vote in favor of this idea regardless :).

+1

-- 
Like Music?
http://l-i-e.com/artists.htm

---

## #24288 — Richard Lynch — 2006-07-07T20:25:49+00:00

URL: https://externals.io/message/24247#24288 · In reply to: #24255

> 
> > […]

Only list what actually GOT installed, with version numbers:

GD version 2
PNG version 1.x.y
JPEG version 2.6.1

Not really any more verbose.

> The problem I have with this is that all of that information is
> already findable from the configure output. Yes, you have to look for
> it, but the idea of a summary is to summarize, not give extensive
> details and basically duplicate all the AC_MSG_CHECKING output. Maybe
> this is something that would only be provided by my --with-
> summary=extended switch?

The problem I have with NOT having it is that about a zillion newbies
don't realize that there WAS an error when they asked for JPEG support
(or whatever) but they don't have JPEG lib installed, or they typed
the wrong magic in ./configure, and the configure process blindly
moves forward and installs "just fine" and then they end up NOT having
JPEG (or whatever) and wonder why there was no error message.

Because the error message was BURIED in a zillion lines of
configure/make output, which appears incomprehensible to the newbie.

Only with many practice runs does one realize that you have to watch
the configure output as it flies by to make sure you get what you
want.

I'd MUCH rather have the default list the modules and versions, and a
"quiet" (or "not-verbose" or ...) option for experts that want to skip
it.

-- 
Like Music?
http://l-i-e.com/artists.htm