Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> dpa-postgres@aegee.org wrote:
>> configure generated by Autoconf loads the file $prefix/etc/config.site and
>> if CFLAGS is defined there, its value is used when building the project.
>> Because in postgresql configure.in contains on line 400 "unset CFLAGS" the
>> value of $CFLAGS from config.site is discarded when building postgresql,
>> contrary to $LDFLAGS from config.site.
> The way it works today completely ignores settings in config.site, which is
> clearly bogus per the above manual, but I doubt that blanket removal of the
> "unset" is the right solution.
I think the thing we'd have to work out is what's the proper interaction
between the template files and the config.site file. It's worth noting
that most of the cases where template files set CFLAGS are when we've
detected a non-default compiler. In such cases, it's not exactly clear
to me that honoring CFLAGS from config.site would be helpful, as such a
setting probably is meant for the default compiler.
Another point here is that any setting coming from config.site is
presumably not going to vary in response to --enable-debug, which
could be problematic, especially so for non-gcc compilers.
Also, it looks to me like the autoconf script will fail outright if
config.site specifies CFLAGS and the user has tried to specify a
different CFLAGS in the environment or command line --- see the
logic that checks for cache file corruption.
In short, I'm pretty dubious about the utility of this feature, which
may explain why nobody has complained about our current behavior
for over a dozen years. Still, it *is* inconsistent that we are
only discarding CFLAGS and not other variables that might come from
such a file.
regards, tom lane