Everything

php

Configure summary

php.internals

Gwynne

20 years ago

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

Richard Lynch

20 years ago

On Mon, July 3, 2006 10:35 am, Gwynne wrote:

> 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

Derick Rethans

20 years ago

On Mon, 3 Jul 2006, Richard Lynch wrote:

> On Mon, July 3, 2006 10:35 am, Gwynne wrote:
> > 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)

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

Derick

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

Sebastian Bergmann

20 years ago

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

Michael Wallner

20 years ago

Sebastian Bergmann wrote:

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

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

Thanks,

--
Michael

Sebastian Bergmann

20 years ago

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

Luca Longinotti

20 years ago

Sebastian Bergmann wrote:

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

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

Michael Wallner

20 years ago

Luca Longinotti wrote:

> Sebastian Bergmann wrote:
>> 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.

> 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

Gwynne

20 years ago

On Jul 5, 2006, at 6:10 AM, Michael Wallner 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?

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

Richard Lynch

20 years ago

On Wed, July 5, 2006 5:16 am, Gwynne wrote:

> On Jul 5, 2006, at 6:10 AM, Michael Wallner 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?
>
> 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

Gwynne

20 years ago

On Jul 3, 2006, at 3:27 PM, Richard Lynch wrote:

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

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

Pierre Joye

20 years ago

Hi,

On 7/3/06, Gwynne <gwynne@skytag.com> wrote:

> 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

Gwynne

20 years ago

On Jul 3, 2006, at 6:09 PM, Pierre wrote:

>> 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. Maybe
this is something that would only be provided by my --with-
summary=extended switch?

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

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

Pierre Joye

20 years ago

On 7/4/06, Gwynne <gwynne@skytag.com> wrote:

> On Jul 3, 2006, at 6:09 PM, Pierre wrote:
> >> 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

Rasmus Lerdorf

20 years ago

Pierre wrote:

> On 7/4/06, Gwynne <gwynne@skytag.com> wrote:
>> On Jul 3, 2006, at 6:09 PM, Pierre wrote:
>> >> 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.

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

Richard Lynch

20 years ago

On Mon, July 3, 2006 5:16 pm, Gwynne wrote:

> On Jul 3, 2006, at 6:09 PM, Pierre wrote:
>> 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