[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wrong order of preprocessor and compiler flags
From: |
Evgeny Grin |
Subject: |
Wrong order of preprocessor and compiler flags |
Date: |
Sun, 27 Mar 2022 18:48:44 +0300 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 |
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/msg00004.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/msg00008.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
- Wrong order of preprocessor and compiler flags,
Evgeny Grin <=