ISTM that the template mechanism used in configure is, well, flawed. Among
the problems:

1) The templates preempt the choice of compiler. A recent report from AIX
said that it automatically picked up the "aix_41" template, only to find
out later on that there is no "cc" compiler on the system. The user had to
specify --with-template=aix_gcc. That is not appropriate for automatic
configuration.

2) Template settings clobber user settings. I expect to be able to write
CFLAGS='-g -pipe' ./configure, but configure will ingore my CFLAGS
setting. The only way to change the CFLAGS is to edit Makefile.global,
which is not an nice thing to invite users to.

In fact, it's questionable why there is a --with-template option at
all. The template names are based on the operating system and the
processor, and in some cases the compiler, all of which we know exactly.

That way we could fix problem 1: we read the templates *after* AC_PROG_CC
has been called. The templates don't contain any information that could
possibly be useful before AC_PROG_CC anyway.

To fix problem 2 I can imagine this procedure: Define a list of variables
that is legal to set in a template. (This can be kept in one place and
extended as needed.) Before doing much of anything, configure checks which
ones of these variables are defined in the environment and remembers
that. After AC_PROG_CC has been called, we read the template and process
all the variables that were not set in the environment.

Any comments?


-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Mon, 10 Jul 2000 09:13:08 -0400 (EDT)
eisentrp@csis.gvsu.edu
Templates
> 2) Template settings clobber user settings. I expect to be able to write
> CFLAGS='-g -pipe' ./configure, but configure will ingore my CFLAGS
> setting. The only way to change the CFLAGS is to edit Makefile.global,
> which is not an nice thing to invite users to.

Just a detail here: Makefile.custom can be used to modify makefile
variables, so Makefile.global never needs to be touched. I manipulate
CFLAGS and other makefile variables using Makefile.custom. As we fix up
./configure, I would hope that we retain this, or a similar, capability.

                    - Thomas

Mon, 10 Jul 2000 14:57:33 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Templates
eisentrp@csis.gvsu.edu wrote:
  >2) Template settings clobber user settings. I expect to be able to write
  >CFLAGS='-g -pipe' ./configure, but configure will ingore my CFLAGS
  >setting. The only way to change the CFLAGS is to edit Makefile.global,
  >which is not an nice thing to invite users to.

Can't we put it in Makefile.custom any more?

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
                 ========================================
     "Delight thyself also in the LORD; and he shall give
      thee the desires of thine heart."                
                                  Psalms 37:4 



Mon, 10 Jul 2000 16:03:09 +0100
"Oliver Elphick" <olly@lfix.co.uk>
Re: Templates 
On Mon, 10 Jul 2000, Thomas Lockhart wrote:

> Just a detail here: Makefile.custom can be used to modify makefile
> variables, so Makefile.global never needs to be touched. I manipulate
> CFLAGS and other makefile variables using Makefile.custom. As we fix up
> ./configure, I would hope that we retain this, or a similar, capability.

Okay, that was going to be my next message. :) Makefile.custom is not the
answer either. You're still inviting users to manually edit files when
they shouldn't have to. In fact, this approach is conceptually wrong
anyway.

The whole point of the configure script is to test whether you can do what
you are trying to do. If you lie to configure and change the settings
manually afterwards, then you lose. If you want to save custom settings
between invocations then you can

1) set the respective variable in the environment

2) create a file config.site in PREFIX/etc or PREFIX/share

3) create some file somewhere and point the environment variable
CONFIG_SITE there.

all requiring that we fix what I'm describing. This way your settings will
have to pass through the scrutiny of configure.

I don't mind keeping the Makefile.custom around if people like it, it's
one extra line in Makefile.global, but I wouldn't recommend it to anyone,
least of all end users.


-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Mon, 10 Jul 2000 11:06:31 -0400 (EDT)
eisentrp@csis.gvsu.edu
Re: Templates
eisentrp@csis.gvsu.edu writes:
> In fact, it's questionable why there is a --with-template option at
> all. The template names are based on the operating system and the
> processor, and in some cases the compiler, all of which we know exactly.

I believe it would be a bad idea to remove the option entirely, because
that would mean that if config.guess and/or configure didn't recognize
your platform, you'd have no simple way of forcing a template choice.
But I agree that --with-template is not the customary way of telling
configure which compiler you want to use.

> That way we could fix problem 1: we read the templates *after* AC_PROG_CC
> has been called. The templates don't contain any information that could
> possibly be useful before AC_PROG_CC anyway.

OK, so you envision:
	1. Pick compiler using standard GNU/configure rules.
	2. If --with-template not specified, assemble template name
	   from config.guess output and compiler name.  (Use .similar
	   substitutions to arrive at actual template from this info.)
	3. Read selected template.
Seems pretty reasonable to me.

> To fix problem 2 I can imagine this procedure: Define a list of variables
> that is legal to set in a template. (This can be kept in one place and
> extended as needed.) Before doing much of anything, configure checks which
> ones of these variables are defined in the environment and remembers
> that. After AC_PROG_CC has been called, we read the template and process
> all the variables that were not set in the environment.

Actually, one point of having the templates is specifically that they
*aren't* very tightly constrained as to what they can set.  Nor do I
believe it's necessarily a good idea to let the user override the
template settings.  If they know enough to do that then let them edit
the template.  CFLAGS is perhaps a special case here --- I could see
appending the environment CFLAGS to what the template has, which we
could do in the templates themselves by making the customary style be
	CFLAGS= whatever $(CFLAGS)
What you sketch above strikes me as a whole lot of mechanism that's
basically fighting the template idea rather than working with it.

			regards, tom lane

Mon, 10 Jul 2000 11:42:48 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Templates 
On Mon, 10 Jul 2000, Tom Lane wrote:

> I believe it would be a bad idea to remove the option entirely, because
> that would mean that if config.guess and/or configure didn't recognize
> your platform, you'd have no simple way of forcing a template choice.

If config.guess doesn't recognize your platform then configure fails,
period. Specifying --with-template isn't going to help. The customary way
to cope with that situation is to use the --host option, which is also
much more flexible in terms of input format.


-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Mon, 10 Jul 2000 12:08:24 -0400 (EDT)
eisentrp@csis.gvsu.edu
Re: Templates 
eisentrp@csis.gvsu.edu writes:
> On Mon, 10 Jul 2000, Tom Lane wrote:
>> I believe it would be a bad idea to remove the option entirely, because
>> that would mean that if config.guess and/or configure didn't recognize
>> your platform, you'd have no simple way of forcing a template choice.

> If config.guess doesn't recognize your platform then configure fails,
> period. Specifying --with-template isn't going to help. The customary way
> to cope with that situation is to use the --host option, which is also
> much more flexible in terms of input format.

config.guess shouldn't even be executed if the user's given
--with-template, IMHO.  However, accepting --host to override
config.guess isn't really the issue here.  The problem is to select an
appropriate template if none of the patterns in template/.similar match
your platform name.  We have had many cases before where the platform
vendor comes out with some random new variant on their uname output that
causes the .similar match to fail (Alpha's "evNN" being the latest
example).  I'd rather be able to tell people "use --with-template=foo"
than have to explain to them how to alter the regexps in .similar.

On another part of the thread, it's true that Makefile.custom is not
intended for random users; it's intended for people who know what they
are doing.  There are enough such people who use it that you will not
get away with removing it ;-)

			regards, tom lane

Mon, 10 Jul 2000 12:23:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Templates 
Tom Lane writes:

> The problem is to select an appropriate template if none of the
> patterns in template/.similar match your platform name.  We have had
> many cases before where the platform vendor comes out with some random
> new variant on their uname output that causes the .similar match to
> fail (Alpha's "evNN" being the latest example).

That's why this is wrong. We currently rely on the OS name, maybe the
complete triple, maybe the uname output. Of course we have no idea whether
it will work.

That is the very reason why config.guess and config.sub were invented, and
that's why we should use them exclusively, IMHO. All the possible outputs
of config.guess are known to us now, so there should be no surprises when
somebody changes their uname.

We ought to make use of the information given to us if possible and not
try to construct our own, much poorer, information instead.


Another problem with --with-template is this:

* user specifies --with-template=foonix_gcc
* template sets CC=gcc
* AC_PROG_CC assumes "gcc" as compiler

Maybe the user's compiler isn't called "gcc", maybe it's called "egcs"
(like mine), or "gcc2", or "/opt/experimental/gcc-3.19/bin/gcc".

Okay, maybe the other way around:

* user runs "CC=egcs ./configure"
* AC_PROG_CC verifies "egcs" as compiler
* template "foonix_gcc" gets chosen
* template sets CC=gcc -- boom!

So the compiler information must disappear from the template files.

If you accept that then we could make --with-template specify the
"template prefix" and the compiler information gets added on if it turns
out there are two templates "name_cc" and "name_gcc". Then we'd have the
procedure

AC_PROG_CC
if --with-template was given, use that
else find one yourself


Btw: Just today someone wrote about this very problem ("[GENERAL] [Help]
INSTALLing 7.02").

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 11 Jul 2000 00:25:26 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Templates 
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> The problem is to select an appropriate template if none of the
>> patterns in template/.similar match your platform name.  We have had
>> many cases before where the platform vendor comes out with some random
>> new variant on their uname output that causes the .similar match to
>> fail (Alpha's "evNN" being the latest example).

> That is the very reason why config.guess and config.sub were invented, and
> that's why we should use them exclusively, IMHO. All the possible outputs
> of config.guess are known to us now, so there should be no surprises when
> somebody changes their uname.

Say what?  The variants we've been having trouble with *are*
config.guess outputs.  Moreover there are new versions of config.guess
all the time.  You're making no sense at all here.

> So the compiler information must disappear from the template files.

Not exactly.  We do need to be able to decide whether we are using
gcc or vendor cc in order to pick the right switches.  One possible
way of doing that is to merge the "cc" and "gcc" templates and have
if-tests in the templates instead.  For example the hpux template
might look like

AROPT=crs
ALL=
SRCH_INC=
SRCH_LIB=
DLSUFFIX=.sl

if test $ac_cv_prog_gcc = yes; then
	CFLAGS=-O2
	SHARED_LIB=-fPIC
	DL_LIB=/usr/lib/libdld.sl
else
	CFLAGS="-Wl,-E -Ae"
	SHARED_LIB=+z
	# Make aCC be first C++ compiler name tried...
	CCC=aCC
fi

That last line brings up an issue that you'll have to deal with before
you can convince me that vanilla autoconf is the only solution we need:
how do you force the thing to use compatible C++ and C compilers?  Right
now it will try to pick g++ (if available) regardless of what you told
it about CC.

			regards, tom lane

Mon, 10 Jul 2000 18:47:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Templates 
Tom Lane writes:

> > So the compiler information must disappear from the template files.
> 
> Not exactly.  We do need to be able to decide whether we are using
> gcc or vendor cc in order to pick the right switches.

I'll rephrase that: The name of the compiler needs to disappear from the
template file. We'd still have a separate file for GCC vs vendor with the
different CFLAGS, etc., but we wouldn't force CC= something.

> One possible way of doing that is to merge the "cc" and "gcc"
> templates and have if-tests in the templates instead.  For example the
> hpux template might look like

Or that, but I'm not sure if that enhances readibility.


> That last line brings up an issue that you'll have to deal with before
> you can convince me that vanilla autoconf is the only solution we need:
> how do you force the thing to use compatible C++ and C compilers?

We use the libtool multi-language branch. :-)  Btw., libtool will need
config.guess either way. Not this release though...


-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 11 Jul 2000 22:34:21 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Templates 
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>>>> So the compiler information must disappear from the template files.
>> 
>> Not exactly.  We do need to be able to decide whether we are using
>> gcc or vendor cc in order to pick the right switches.

> I'll rephrase that: The name of the compiler needs to disappear from the
> template file. We'd still have a separate file for GCC vs vendor with the
> different CFLAGS, etc., but we wouldn't force CC= something.

Agreed.

>> One possible way of doing that is to merge the "cc" and "gcc"
>> templates and have if-tests in the templates instead.  For example the
>> hpux template might look like

> Or that, but I'm not sure if that enhances readibility.

If you're doing the legwork I guess you get to choose ;-) ... but I like
the idea of combining the gcc and vendor-cc templates for a platform.
Usually there's a great deal of commonality, so having two templates
just means two files to edit (or forget to edit).

			regards, tom lane

Tue, 11 Jul 2000 17:09:44 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Templates 
Tom Lane writes:

> Say what?  The variants we've been having trouble with *are*
> config.guess outputs.  Moreover there are new versions of config.guess
> all the time.  You're making no sense at all here.

Wait, didn't you say the problem was from vendors changing their uname
output? We know what config.guess can print, it's in the source. When new
versions come out we can read the ChangeLog. The Alpha problem you
mentioned could have been solved by writing "alpha.*" instead of just
"alpha". I don't believe relying on uname would have made this better.


-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 12 Jul 2000 02:24:26 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Templates 