Re: Templates - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Templates
Date
Msg-id 826.963243768@sss.pgh.pa.us
Whole thread Raw
In response to Templates  (eisentrp@csis.gvsu.edu)
Responses Re: Templates  (eisentrp@csis.gvsu.edu)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Re: [GENERAL] PostgreSQL vs. MySQL
Next
From: Tom Lane
Date:
Subject: Re: postgres fe/be protocol