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 <k2k@xxxxxxxx> wrote: > On 24.03.2022 21:37, Nick Bowler wrote: > > On 2022-03-24, Zack Weinberg <zack@xxxxxxxxxxxx> 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 autoconf@xxxxxxx list >
