Thread: Templates
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
> 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
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 thineheart." Psalms 37:4
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
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
templatename from config.guess output and compiler name. (Use .similar substitutions to arrive at actual template
fromthis 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 beCFLAGS= 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
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
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
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
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; thenCFLAGS=-O2SHARED_LIB=-fPICDL_LIB=/usr/lib/libdld.sl
elseCFLAGS="-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
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
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
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