Re: Wrong order of preprocessor and compiler flags

[Alex Ameen]

The rationale for placement of `CPPFLAGS` early is to allow users to better
control include ordering. This is similar to why `CFLAGS` is last.

Consider this situation :

User wants to preempt the default include path, and wants to override the C
standard.

make CPPFLAGS='-Ifoo/bar' CFLAGS='-std=c18';

If `CPPFLAGS` were at the end, the user must use `-quote foo/bar` to
successfully preempt which has a different meaning in some edge cases.
Notably if the includes are in carrots rather than quotes it ain't gonna
work.

In both cases the ordering is intended to allow users to override defaults.
I agree that this ordering isn't ideal for other flags like `-D`, but
considering a change would break builds with existing work arounds I think
any reordering is going to rouse the masses into an angry stupor.

On Thu, Mar 24, 2022, 2:31 PM Evgeny Grin  wrote:

> On 24.03.2022 21:37, Nick Bowler wrote:
> > On 2022-03-24, Zack Weinberg  wrote:
> >> On Thu, Mar 24, 2022, at 11:13 AM, Nick Bowler wrote:
> >>> However, GNU coding standards state that CFLAGS should be the last
> >>> item on compilation commands, so it would appear that this is a case
> >>> where traditional "make" behaviour contrasts with GNU standards (which
> >>> Automake is following).
> >>
> >> Huh.  Is there a rationale given in the coding standard?  If not, do you
> >> have any idea who might remember the rationale?
> >
> > The GNU standards just say this[1]:
> >
> >"Put CFLAGS last in the compilation command, after other variables
> > containing compiler options, so the user can use CFLAGS to override
> > the others."
> >
> > When it comes to C(PP)FLAGS the concept of "overriding" options is a
> > bit hairy -- many C compiler options do not have direct methods to undo
> > their effects -- but whatever.
> >
> > [1] https://www.gnu.org/prep/standards/standards.html#Command-Variables
> >
>
> Actually example in the GNU standards doesn't use CPPFLAGS, while a few
> lines above it's clearly mentioned "Use CPPFLAGS in any compilation
> command that runs the preprocessor". Compiler runs preprocessor
> internally, so example should have CPPFLAGS with $(CC).
>
> Anyway, I suggest to not read this too literally, but instead see the
> idea behind.
> The idea is to give user freedom to override any supplied flags. For
> automake[1] it is supported by AM_CFLAGS, foo_CFLAGS, and CFLAGS.
> CFLAGS must be always used after AM_CFLAGS, so user can easily override
> final behaviour without makefiles patching.
>
>
> To align with make implementations, that never use CPPFLAGS before
> CFLAGS [2] and follow the GNU coding standard, I suggest to use the next
> combination of flags:
> $(CC) $(AM_CFLAGS) $(AM_CPPFLAGS) $(CFLAGS) $(CPPFLAGS) -c
>
> CFLAGS and CPPFLAGS are designed to be used by the user. With this
> combination user may override any upstream-supplied AM_CFLAGS and
> AM_CPPFLAGS by CFLAGS (and by CPPFLAGS as well) so GNU standards are
> met. At the same time all CPPFLAGS are used after CFLAGS and this is
> aligned with all 'make' implementations.
>
>
> [1]
>
> https://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering
> [2] https://lists.gnu.org/archive/html/autoconf/2022-03/msg00010.html
>
> --
> Evgeny
>
> PS Let's move this discussion to the autoc...@gnu.org list
>

Re: Wrong order of preprocessor and compiler flags

[Evgeny Grin]

On 24.03.2022 21:37, Nick Bowler wrote:

On 2022-03-24, Zack Weinberg  wrote:

On Thu, Mar 24, 2022, at 11:13 AM, Nick Bowler wrote:

However, GNU coding standards state that CFLAGS should be the last
item on compilation commands, so it would appear that this is a case
where traditional "make" behaviour contrasts with GNU standards (which
Automake is following).


Huh.  Is there a rationale given in the coding standard?  If not, do you
have any idea who might remember the rationale?


The GNU standards just say this[1]:

   "Put CFLAGS last in the compilation command, after other variables
containing compiler options, so the user can use CFLAGS to override
the others."

When it comes to C(PP)FLAGS the concept of "overriding" options is a
bit hairy -- many C compiler options do not have direct methods to undo
their effects -- but whatever.

[1] https://www.gnu.org/prep/standards/standards.html#Command-Variables



Actually example in the GNU standards doesn't use CPPFLAGS, while a few 
lines above it's clearly mentioned "Use CPPFLAGS in any compilation 
command that runs the preprocessor". Compiler runs preprocessor 
internally, so example should have CPPFLAGS with $(CC).


Anyway, I suggest to not read this too literally, but instead see the 
idea behind.
The idea is to give user freedom to override any supplied flags. For 
automake[1] it is supported by AM_CFLAGS, foo_CFLAGS, and CFLAGS.
CFLAGS must be always used after AM_CFLAGS, so user can easily override 
final behaviour without makefiles patching.



To align with make implementations, that never use CPPFLAGS before 
CFLAGS [2] and follow the GNU coding standard, I suggest to use the next 
combination of flags:

$(CC) $(AM_CFLAGS) $(AM_CPPFLAGS) $(CFLAGS) $(CPPFLAGS) -c

CFLAGS and CPPFLAGS are designed to be used by the user. With this 
combination user may override any upstream-supplied AM_CFLAGS and 
AM_CPPFLAGS by CFLAGS (and by CPPFLAGS as well) so GNU standards are 
met. At the same time all CPPFLAGS are used after CFLAGS and this is 
aligned with all 'make' implementations.



[1] 
https://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering

[2] https://lists.gnu.org/archive/html/autoconf/2022-03/msg00010.html

--
Evgeny

PS Let's move this discussion to the autoc...@gnu.org list


OpenPGP_0x460A317C3326D2AE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Wrong order of preprocessor and compiler flags

[Evgeny Grin]

 Original Message 
From: Evgeny Grin 
Sent: Thursday, March 24, 2022, 14:26 UTC+3
Subject: Wrong order of preprocessor and compiler flags




I've found that everywhere in autoconf scripts flags are used like:
$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >_MESSAGE_LOG_FD
while automake and libtool use flags in the other order:
$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) 
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)


I agree that this should be made consistent, but before we change 
anything, we need to check what the rules *built into GNU and BSD 
Make* do with CFLAGS and CPPFLAGS (and also CXXFLAGS, OBJCFLAGS, etc) 
because those are much much harder to get changed than anything in 
Automake or Autoconf, so we should aim to harmonize everything with them.


Can you look into that please, Evgeny?

Yes, definitely makes sense to align with major 'make' implementations, 
as all autotools are build to top of them.

I'll check it.



I've made some experiments and research.
In this message, I would like to simply state the current situation.

Debian SID
---
Variables defined in 
https://git.savannah.gnu.org/cgit/make.git/tree/src/default.c?id=667d70eac2b5c0d7b70941574fd51a76ae93b0f4#n606

"COMPILE.c", "$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c"
"COMPILE.cc", "$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c"
===
$ LC_ALL=C make -v
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ touch Makefile testc.c testcpp.cc

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testc.o
cc -g0 -DNICE_MACRO  -c -o testc.o testc.c

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testcpp.o
g++ -g1 -DNICE_MACRO  -c -o testcpp.o testcpp.cc
===


FreeBSD 13.0.
---
Suffixes defined in /usr/share/mk/bsd.suffixes.mk:
.c.o:
${CC} ${STATIC_CFLAGS} ${CFLAGS} -c ${.IMPSRC} -o ${.TARGET}
${CTFCONVERT_CMD}
.cc.o .cpp.o .cxx.o .C.o:
${CXX} ${STATIC_CXXFLAGS} ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET}
===
$ make -V MAKE_VERSION
20210110

$ touch Makefile testc.c testcpp.cc

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testc.o
cc  -g0 -c testc.c -o testc.o

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testcpp.o
c++  -g1 -c testcpp.cc -o testcpp.o
===


OpenBSD 7.0
---
Variables defined in /usr/share/mk/sys.mk:
COMPILE.c?= ${CC} ${CFLAGS} ${CPPFLAGS} -c
COMPILE.cc?=${CXX} ${CXXFLAGS} ${CPPFLAGS} -c
===
$ touch Makefile testc.c testcpp.cc

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testc.o
cc -g0 -DNICE_MACRO -c testc.c

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testcpp.o
c++ -g1 -DNICE_MACRO -c testcpp.cc
===


NetBSD 9
---
Variables defined in /usr/share/mk/sys.mk:
COMPILE.c?= ${CC} ${CFLAGS} ${DTRACE_OPTS} ${CPPFLAGS} -c
COMPILE.cc?=${CXX} ${_CXXSEED} ${CXXFLAGS} ${DTRACE_OPTS} ${CPPFLAGS} -c
===
$ touch Makefile testc.c testcpp.cc

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testc.o
cc -g0  -DNICE_MACRO -c testc.c

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testcpp.o
c++  -g1  -DNICE_MACRO -c testcpp.cc
===


Solaris 11.4
---
Variables defined in /usr/share/lib/make/make.rules:
COMPILE.c=$(CC) $(CFLAGS) $(CPPFLAGS) -c
COMPILE.cc=$(CCC) $(CCFLAGS) $(CPPFLAGS)  -c
===
$ touch Makefile testc.c testcpp.cc

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testc.o
cc -g0 -DNICE_MACRO -c  testc.c
"testc.c", line 1: warning: empty translation unit

$ make CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 CCFLAGS=-g2 testcpp.o
CC -g2 -DNICE_MACRO  -c  testcpp.cc

$ rm -f *.o

$ dmake --version
dmake: Studio 12.6 Distributed Make 8.4 SunOS_x64 2017/05/30

$ dmake -m serial CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 
CCFLAGS=-g2 testc.o

cc -g0 -DNICE_MACRO -c  testc.c
"testc.c", line 1: warning: empty translation unit

$ dmake -m serial CPPFLAGS=-DNICE_MACRO CFLAGS=-g0 CXXFLAGS=-g1 
CCFLAGS=-g2 testcpp.o

CC -g2 -DNICE_MACRO  -c  testcpp.cc
===


Conclusions:
* All checked "make" implementations, except FreeBSD's "make", use 
"${CFLAGS} ${CPPFLAGS}";

* FreeBSD's "make" doesn't use CPPFLAGS at all
* No checked "make" implementation uses CPPFLAGS before CFLAGS

Looks like FreeBSD follows POSIX which has nothing about CPPFLAGS:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_76_13_09

--
Evgeny

PS Sorry for crossposting. Let's more this discussion to the 
autoc...@gnu.org list.


OpenPGP_0x460A317C3326D2AE.asc
Description: OpenPGP public key


OpenPGP_signature

Re: Wrong order of preprocessor and compiler flags

[Nick Bowler]

On 2022-03-24, Zack Weinberg  wrote:
> On Thu, Mar 24, 2022, at 11:13 AM, Nick Bowler wrote:
>> However, GNU coding standards state that CFLAGS should be the last
>> item on compilation commands, so it would appear that this is a case
>> where traditional "make" behaviour contrasts with GNU standards (which
>> Automake is following).
>
> Huh.  Is there a rationale given in the coding standard?  If not, do you
> have any idea who might remember the rationale?

The GNU standards just say this[1]:

  "Put CFLAGS last in the compilation command, after other variables
   containing compiler options, so the user can use CFLAGS to override
   the others."

When it comes to C(PP)FLAGS the concept of "overriding" options is a
bit hairy -- many C compiler options do not have direct methods to undo
their effects -- but whatever.

[1] https://www.gnu.org/prep/standards/standards.html#Command-Variables

Re: Wrong order of preprocessor and compiler flags

[Zack Weinberg]

On Thu, Mar 24, 2022, at 11:13 AM, Nick Bowler wrote:
> On 2022-03-23, Zack Weinberg  wrote:
>> ... before we change
>> anything, we need to check what the rules *built into GNU and BSD
>> Make* do with CFLAGS and CPPFLAGS (and also CXXFLAGS, OBJCFLAGS, etc)
>> because those are much much harder to get changed than anything in
>> Automake or Autoconf, so we should aim to harmonize everything with
>> them.
>
> Practically all make implementations use the $(CFLAGS) $(CPPFLAGS)
> ordering in their builtin .c.o inference rules.
>
> However, GNU coding standards state that CFLAGS should be the last
> item on compilation commands, so it would appear that this is a case
> where traditional "make" behaviour contrasts with GNU standards (which
> Automake is following).

Huh.  Is there a rationale given in the coding standard?  If not, do you have 
any idea who might remember the rationale?

zw

Re: Wrong order of preprocessor and compiler flags

[Nick Bowler]

On 2022-03-23, Zack Weinberg  wrote:
> On Wed, Mar 23, 2022, at 11:31 AM, Evgeny Grin wrote:
>> I've found that everywhere in autoconf scripts flags are used like:
>> $CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >_MESSAGE_LOG_FD
>> while automake and libtool use flags in the other order:
>> $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS)
>> $(AM_CFLAGS) $(CFLAGS)
>
> I agree that this should be made consistent, but before we change
> anything, we need to check what the rules *built into GNU and BSD
> Make* do with CFLAGS and CPPFLAGS (and also CXXFLAGS, OBJCFLAGS, etc)
> because those are much much harder to get changed than anything in
> Automake or Autoconf, so we should aim to harmonize everything with
> them.

Practically all make implementations use the $(CFLAGS) $(CPPFLAGS)
ordering in their builtin .c.o inference rules.

However, GNU coding standards state that CFLAGS should be the last
item on compilation commands, so it would appear that this is a case
where traditional "make" behaviour contrasts with GNU standards (which
Automake is following).

Cheers,
  Nick

Re: Wrong order of preprocessor and compiler flags

[Evgeny Grin]

I've found that everywhere in autoconf scripts flags are used like:
$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >_MESSAGE_LOG_FD
while automake and libtool use flags in the other order:
$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) 
$(AM_CFLAGS) $(CFLAGS)


I agree that this should be made consistent, but before we change anything, we 
need to check what the rules *built into GNU and BSD Make* do with CFLAGS and 
CPPFLAGS (and also CXXFLAGS, OBJCFLAGS, etc) because those are much much harder 
to get changed than anything in Automake or Autoconf, so we should aim to 
harmonize everything with them.


Can you look into that please, Evgeny?

Yes, definitely makes sense to align with major 'make' implementations, 
as all autotools are build to top of them.

I'll check it.

--
Evgeny


OpenPGP_0x460A317C3326D2AE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Wrong order of preprocessor and compiler flags

[Zack Weinberg]

On Wed, Mar 23, 2022, at 11:31 AM, Evgeny Grin wrote:
> Hello,
>
> I've found that everywhere in autoconf scripts flags are used like:
> $CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >_MESSAGE_LOG_FD
> while automake and libtool use flags in the other order:
> $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) 
> $(AM_CFLAGS) $(CFLAGS)

I agree that this should be made consistent, but before we change anything, we 
need to check what the rules *built into GNU and BSD Make* do with CFLAGS and 
CPPFLAGS (and also CXXFLAGS, OBJCFLAGS, etc) because those are much much harder 
to get changed than anything in Automake or Autoconf, so we should aim to 
harmonize everything with them.

Can you look into that please, Evgeny?

zw