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

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


On Sun, Mar 27, 2022, 5:00 PM Jan Engelhardt <jeng...@inai.de <mailto:jeng...@inai.de>> 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
    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
    but even back then in '94, the documentation was inconsistent, sometimes
    providing example descriptions where CPPFLAGS comes after
    and sometimes reversed.

Attachment: OpenPGP_0x460A317C3326D2AE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to