On 2015-10-28 11:42:28 -0400, Tom Lane wrote: > In view of your point (1), I'd be okay with inventing an EXTRA_CFLAGS > argument that is added to, rather than replacing, the automatically > computed flags. But I think that configure must include such flags > for its own compile runs, else it is not testing the true build > environment and might get wrong answers.
Ok. > Is -Werror the only practical case where we need configure to *not* see > a flag that should otherwise be applied? If so, maybe we should just > attack that problem directly and narrowly. I can think of at least > two ways: I can't really any that aren't of the form -Werror or -Werror=specific-warning. I'm not sure that the latter is particularly interesting, using -Werror and then -Wno-error=xxx seems like it'd usually be better. > 1. Invent a "--with-werror" configure switch that causes -Werror to be > added to the CFLAGS, but not while running tests that it'd break. > > 2. Explicitly filter -Werror out of the user-provided CFLAGS while running > tests that it'd break. I think either of these is fine - I've a slight preference for 2) because we already filter *FLAGS in a bunch of places and it seems a bit nicer to extend, should another similar case come up. Do you have a preference? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
