Re: Wrong order of preprocessor and compiler flags

[Evgeny Grin]

Hello Alex,

On 28.03.2022 4:55, Alex Ameen wrote:
This is a message I meant send to "all", I'm sending again for the wider 
discussion.


Please let me know if my understanding of include order is incorrect. 
Essentially I'm more concerned about relative placement of `AM_CPPFLAGS' 
and `CPPFLAGS' in any future changes.


Moving CPPFLAGS to the end of the line prevents users from overriding 
include paths.


Currently flags are used in automake as
AM_CPPFLAGS CPPFLAGS AM_CFLAGS CFLAGS

Actually, there is *no way* to override include path defined in 
AM_CPPFLAGS (unless AM_CPPFLAGS is redefined in command line, which is 
not right way). Any include search paths defined in CPPFLAGS and in 
CFLAGS will be added to the end of the search list.


On the other hand, this is a right thing. As defined in the same section 
of the GNU Coding Standards [1], there are two types of flags. The first 
type is flags required for proper compilation.
For example: when building library, I need root of build path for the 
lib's "configure.h" and the lib's includes directory. They must be the 
first items in the include search path, like

AM_CPPFLAGS="-I../../builddir -I../lib/include"
If user will override (prepend) with "-I/usr/include 
-I/usr/include/polly/Config" it would break the compilation, because 
lib's installed header will be used instead of header in sources dir and 
polly's config.h will be found first instead of lib's config.h.


I believe it's current placement is intended to provide an avenue for 
overrides in the same way that CFLAGS being at the end allows users to 
override the C standards and spec flags.


Really what I care about is the relative order of `CPPFLAGS 
AM_CPPFLAGS', and `AM_CFLAGS CFLAGS' - whether these groups are ordered 
before or after the other group is less important though. For example 
I'm content with either `CPPFLAGS AM_CPPFLAGS AM_CFLAGS CFLAGS' or 
`AM_CFLAGS CFLAGS CPPFLAGS AM_CPPFLAGS'.


My suggestion with "AM_CFLAGS AM_CPPFLAGS CFLAGS CPPFLAGS" gives user 
the same level of freedom on flags overriding as current "AM_CPPFLAGS 
CPPFLAGS AM_CFLAGS CFLAGS", CFLAGS still override any AM_* flags, and 
order of used flags is the same as tested by "configure".



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

--
Evgeny

On Sun, Mar 27, 2022, 5:00 PM Jan Engelhardt > wrote:



On Sunday 2022-03-27 23:22, Karl Berry wrote:

 >It seems the basic inconsistency is whether CPPFLAGS is considered a
 >"user variable" or not. In earlier eras, it wasn't [...]

In earlier eras of what exactly?

As for make, it never made a distinction between user variables or
otherwise,
at least that's the way make comes across. Some software will just
break on `make CFLAGS=-O3` and others will work to compile.

As for automake, AM_CPPFLAGS was introduced at the same time as
AM_CFLAGS as
per the git log. So CPPFLAGS always was a user variable.

 >[more on CFLAGS<->CPPFLAGS order]

I went to the GNU make git repo to check on CPPFLAGS; it appeared
first in
documentation rather than source (which seems like a history import
mishap),
but even back then in '94, the documentation was inconsistent, sometimes
providing example descriptions where CPPFLAGS comes after
CFLAGS/FFLAGS/etc.,
and sometimes reversed.



OpenPGP_0x460A317C3326D2AE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Wrong order of preprocessor and compiler flags

[Evgeny Grin]

Hello Karl,


On 28.03.2022 0:22, Karl Berry wrote:

It seems the basic inconsistency is whether CPPFLAGS is considered a
"user variable" or not. In earlier eras, it wasn't, but from your msg,
I gather it is now.

The GNU standards node about it, that you mentioned,
   https://www.gnu.org/prep/standards/standards.html#Command-Variables
does not clearly state it one way or another. But its example shows
CFLAGS after CPPFLAGS.


The same example puts "-I." into ALL_CFLAGS, which makes even harder to 
guess the right idea how to use CPPFLAGS.



Thus I think a prior step is to write bug-standa...@gnu.org and suggest
clarifying the status of CPPFLAGS, its relationship to CFLAGS, etc.


Definitely makes sense.
I'll write to the standards list.


We could consider changing automake to follow autoconf even if the GCS
is not changed, but it would be better if the GCS were clear.

 2. Use AM_CFLAGS CFLAGS AM_CPPFLAGS CPPFLAGS. This is more aligned with
 current flags grouping, but CFLAGS will not override definitions in
 AM_CPPFLAGS (less aligned with GNU Standards).

It seems wrong (and disastrously backwards-incompatible) to me for
CFLAGS not to override AM_everything. Your option 1:

 1. Use AM_CFLAGS AM_CPPFLAGS CFLAGS CPPFLAGS. I think this is the best
 option. As required by GNU Standards, CFLAGS still override all
 upstream-defined flags.

seems like the best option to me too. --thanks, karl.


--
Evgeny

Wrong order of preprocessor and compiler flags

[Evgeny Grin]

Hello,

This discussion was started initially in the autoconf list. [1]
Automake and autoconf use compiler and preprocessor flags in different 
order.

Within 'configure' scripts, compile checks/tests are performed as [2]:
$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&AS_MESSAGE_LOG_FD
but resulting flags are used in another order in automake makefiles:
$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) 
$(AM_CFLAGS) $(CFLAGS)


Automake uses CPPFLAGS before CFLAGS [3].

In the following research I found than no 'make' implementation uses 
CPPFLAGS before CFLAGS [4]. Almost all 'make' implementations (GNU, 
OpenBSD, NetBSD, Solaris) put CPPFLAGS after CFLAGS, the only exception 
is FreeBSD version, which doesn't use CPPFLAGS at all.


glibc uses CFLAGS before CPPFLAGS [5][6].

While usage of CPPFLAGS before CFLAGS looks more logical, seems that 
majority of the software tools use flags in other order.


GNU Coding Standards recommends to put CFLAGS at the end of command line 
parameters [7] to give user ability to override upstream-supplied flags.


I think that automake should be aligned with other tools for several 
reasons:
* automated build systems are using the same CFLAGS, CPPFLAGS for 
packages built with autotools and pure Makefiles. Currently if may give 
different results.
* 'configure' results are based on CFLAGS CPPFLAGS, but automake's 
makefiles use CPPFLAGS CFLAGS which may produce result different from 
expected.


I see several ways to implement it in automake:
1. Use AM_CFLAGS AM_CPPFLAGS CFLAGS CPPFLAGS. I think this is the best 
option. As required by GNU Standards, CFLAGS still override all 
upstream-defined flags.
2. Use AM_CFLAGS CFLAGS AM_CPPFLAGS CPPFLAGS. This is more aligned with 
current flags grouping, but CFLAGS will not override definitions in 
AM_CPPFLAGS (less aligned with GNU Standards).

3. Use AM_CFLAGS AM_CPPFLAGS CPPFLAGS CFLAGS.
4. Use AM_CPPFLAGS AM_CFLAGS CFLAGS CPPFLAGS.
Although I can find arguments for the last two options, I don't think 
they make any real sense.


To avoid any possible breakage of existing packages, some new automake 
option could be introduced, with name like "right-flags-order" with 
warning that flag will be default soon.


I may work on patches, if my proposal will be accepted.


[1] https://lists.gnu.org/archive/html/autoconf/2022-03/msg4.html
[2] 
https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=lib/autoconf/c.m4;hb=00358457d09c19ff6b5ec7ed98708540d1994a5f#l64
[3] 
https://git.savannah.gnu.org/cgit/automake.git/tree/bin/automake.in?id=fee9a828bcc968656edfc89e38b157c28d6335f0#n700

[4] https://lists.gnu.org/archive/html/autoconf/2022-03/msg00010.html
[5] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=Makefile;hb=305769b2a15c2e96f9e1b5195d3c4e0d6f0f4b68#l528

[6] https://lists.gnu.org/archive/html/autoconf/2022-03/msg8.html
[7] https://www.gnu.org/prep/standards/standards.html#Command-Variables

--
Evgeny


OpenPGP_0x460A317C3326D2AE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature