Re: Wrong order of preprocessor and compiler flags

[Alex Ameen]

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.

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'.


On Sun, Mar 27, 2022, 5:00 PM Jan Engelhardt <jengelh@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
> 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.
>