Обсуждение: Add EXTRA_CFLAGS to configure
Hi, I rather regularly want to pass extra flags to configure without overwriting CFLAGS. There's two basic reasons: 1) ./configure CFLAGS=... essentially breaks --enable-debug and related options, overwrites -O2 as the default and such.That's imo pretty confusing. 2) I like to be able to pass -Werror or something to configure without breaking a bunch of configure tests that won't workwith Werror. A good way to do that seems to be to add a separate variable for that purpose? Unless someobdy has a better idea? Greetings, Andres Freund
On Wed, Oct 28, 2015 at 11:55 AM, Andres Freund <andres@anarazel.de> wrote: > I rather regularly want to pass extra flags to configure without > overwriting CFLAGS. There's two basic reasons: > > 1) ./configure CFLAGS=... essentially breaks --enable-debug and related > options, overwrites -O2 as the default and such. That's imo pretty > confusing. > 2) I like to be able to pass -Werror or something to configure without > breaking a bunch of configure tests that won't work with Werror. > > A good way to do that seems to be to add a separate variable for that > purpose? Unless someobdy has a better idea? I use COPT for this purpose. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2015-10-28 12:20:22 +0100, Robert Haas wrote: > On Wed, Oct 28, 2015 at 11:55 AM, Andres Freund <andres@anarazel.de> wrote: > > I rather regularly want to pass extra flags to configure without > > overwriting CFLAGS. There's two basic reasons: > > > > 1) ./configure CFLAGS=... essentially breaks --enable-debug and related > > options, overwrites -O2 as the default and such. That's imo pretty > > confusing. > > 2) I like to be able to pass -Werror or something to configure without > > breaking a bunch of configure tests that won't work with Werror. > > > > A good way to do that seems to be to add a separate variable for that > > purpose? Unless someobdy has a better idea? > > I use COPT for this purpose. Unless I miss something you can't just pass that to configure though, right? I.e. it has to be passed to each make invocation? Andres
Andres Freund <andres@anarazel.de> writes:
> I rather regularly want to pass extra flags to configure without
> overwriting CFLAGS. There's two basic reasons:
> 1) ./configure CFLAGS=... essentially breaks --enable-debug and related
> options, overwrites -O2 as the default and such. That's imo pretty
> confusing.
> 2) I like to be able to pass -Werror or something to configure without
> breaking a bunch of configure tests that won't work with Werror.
I would be rather surprised if such a switch didn't affect the flags used
by configure itself, so your point (2) seems like it would require nasty
inconsistency.
Why don't you just edit Makefile.global after configure finishes?
Or use COPT or PROFILE?
regards, tom lane
On Wed, Oct 28, 2015 at 2:17 PM, Andres Freund <andres@anarazel.de> wrote: >> I use COPT for this purpose. > > Unless I miss something you can't just pass that to configure though, > right? I.e. it has to be passed to each make invocation? What I do is: echo COPT=-Wall -Werror > src/Makefile.custom -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Oct 28, 2015 at 02:42:19PM +0100, Robert Haas wrote: > On Wed, Oct 28, 2015 at 2:17 PM, Andres Freund <andres@anarazel.de> wrote: > >> I use COPT for this purpose. > > > > Unless I miss something you can't just pass that to configure though, > > right? I.e. it has to be passed to each make invocation? > > What I do is: > > echo COPT=-Wall -Werror > src/Makefile.custom Make will pick up variables from the environment. So unless the makefile goes out of its way to circumvent it, you can just do COPT=-Werror export COPT and then run your usual configure/compile cycle. There's no specific need to modify the makefiles or pass extra arguments into make. -- nw
On 2015-10-28 09:36:39 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > I rather regularly want to pass extra flags to configure without > > overwriting CFLAGS. There's two basic reasons: > > > 1) ./configure CFLAGS=... essentially breaks --enable-debug and related > > options, overwrites -O2 as the default and such. That's imo pretty > > confusing. > > 2) I like to be able to pass -Werror or something to configure without > > breaking a bunch of configure tests that won't work with Werror. > > I would be rather surprised if such a switch didn't affect the flags used > by configure itself, so your point (2) seems like it would require nasty > inconsistency. Hm, I don't find it that inconsistent to say that configure itself uses CFLAGS but not EXTRA_CFLAGS (or whatever). > Why don't you just edit Makefile.global after configure finishes? I personally do, and it's not a problem for me because I call configure and everything from scripts anyway. But it's harder to to tell people that. It's e.g. much easier to tell people that they should add one argument to configure to specify -fno-omit-frame-pointer rather than having to create Makefile.custom or something like that. Makefile.custom doesn't, afaik, won't forward the cflags to PGXS built extensions. Which then is annoying for flags like -fno-omit-frame-pointer. > Or use COPT or PROFILE? If we'd persist COPT or PROFILE when specified for configure that'd work for me as well. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> On 2015-10-28 09:36:39 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> 1) ./configure CFLAGS=... essentially breaks --enable-debug and related
>>> options, overwrites -O2 as the default and such. That's imo pretty
>>> confusing.
>>> 2) I like to be able to pass -Werror or something to configure without
>>> breaking a bunch of configure tests that won't work with Werror.
>> I would be rather surprised if such a switch didn't affect the flags used
>> by configure itself, so your point (2) seems like it would require nasty
>> inconsistency.
> Hm, I don't find it that inconsistent to say that configure itself uses
> CFLAGS but not EXTRA_CFLAGS (or whatever).
Well, it is. In particular, you could easily shoot yourself in the foot
this way, for example by passing some semantically relevant switch like
"-m64" in the wrong set of flags.
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.
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:
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.
regards, tom lane
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
Andres Freund <andres@anarazel.de> writes:
> On 2015-10-28 11:42:28 -0400, Tom Lane wrote:
>> 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?
I'd go with #2 also, if it's not hard to implement. Single-purpose
configure switches are a wart.
regards, tom lane
On 10/28/15 6:55 AM, Andres Freund wrote: > 1) ./configure CFLAGS=... essentially breaks --enable-debug and related > options, If assigning to CFLAGS breaks --enable-debug, then we should fix that by reordering things a bit. > overwrites -O2 as the default and such. That's imo pretty > confusing. I'm not so concerned about this case. -O2 is a default, and if you want something different, then the default doesn't apply. If a user works at this level of detail, they can also keep that in mind. Adding more ways to set the same thing would just create more potentional uncertainty about in which order and precedence things are set and checked. It might make sense to you now, but that doesn't mean in will make sense to the next person. > 2) I like to be able to pass -Werror or something to configure without > breaking a bunch of configure tests that won't work with Werror. > > A good way to do that seems to be to add a separate variable for that > purpose? Unless someobdy has a better idea? I think we already had this discussion numerous times, and about all the ways that have been proposed have been rejected at least once before. ;-)
On Wed, Oct 28, 2015 at 01:53:31PM +0000, Nathan Wagner wrote: > On Wed, Oct 28, 2015 at 02:42:19PM +0100, Robert Haas wrote: > > On Wed, Oct 28, 2015 at 2:17 PM, Andres Freund <andres@anarazel.de> wrote: > > >> I use COPT for this purpose. > > > > > > Unless I miss something you can't just pass that to configure though, > > > right? I.e. it has to be passed to each make invocation? > > > > What I do is: > > > > echo COPT=-Wall -Werror > src/Makefile.custom > > Make will pick up variables from the environment. So unless the > makefile goes out of its way to circumvent it, you can just do > > COPT=-Werror > export COPT > > and then run your usual configure/compile cycle. There's no > specific need to modify the makefiles or pass extra arguments > into make. FYI, I use CUSTOM_COPT in src/Makefile.custom. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +