Configure summary

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

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 :)

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

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 :)

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

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.

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