Add EXTRA_CFLAGS to configure

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. ;-)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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                             +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers