On 2015-01-15 09:25:29 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > FWIW, if we moved the
> > CFLAGS="$CFLAGS $user_CFLAGS"
> > further down, it'd have advantage that compiling with -Werror would be
> > more realistic. Right now doing so breaks about half of the feature
> > checking configure checks because of warnings. E.g. on my platform it
> > fails to detect 64bit integers, inline, ...
>
> Given the way autoconf works, I think trying to run the configure tests
> with -Werror is a fool's errand.
Yea, agreed.
> OTOH, not applying the user's CFLAGS during configure is a nonstarter
> as well.
Fair enough. What about just filtering out -Werror during configure
alone? Or just specifying -Wno-error during it? Given that it really
can't work properly, that seems like a relatively simple solution.
> So rather than trying to inject -Werror via generic CFLAGS, it would
> likely be better to have some means of injecting it only into the
> actual build and not into the configure run.
>
> There is at least one way to do that already (Makefile.custom). Not
> sure if it's worth inventing an --enable-warnings-as-errors type of
> switch to do it more directly.
I think Makefile.custom is really rather hard to discover for new
developers. That its inclusion is commented with
# NOTE: Makefile.custom is from the pre-Autoconf days of PostgreSQL.
# You are liable to shoot yourself in the foot if you use it without
# knowing exactly what you're doing. The preferred (and more
# reliable) method is to communicate what you want to do to the
# configure script, and leave the makefiles alone.
doesn't help...
I'd also like to have a easy way of adding CFLAGS to configure, instead
of overwriting them. There's COPT for make, but that doesn't persist...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services