From: | eisentrp(at)csis(dot)gvsu(dot)edu |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Templates |
Date: | 2000-07-10 15:06:31 |
Message-ID: | Pine.LNX.4.21.0007101055060.19559-100000@eos05.csis.gvsu.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-07-10 15:11:51 | Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... |
Previous Message | Oliver Elphick | 2000-07-10 15:03:09 | Re: Templates |