2012/6/24 Russ Allbery wrote: >> If you do, then... How should they do that? I.e. if I specify: >> CPPFLAGS="blablabla hehehe hohoho" >> How should build system run gcc? Like that? >> gcc blablabla hehehe hohoho -c -o test.o test.c > > Yes.
Why? Just to have it autotools-compatible? If I was writing a custom build system I would be thinking about using -Wp option, since that's exactly why it's there for — to pass some options to the preprocessor (or, being honest, I would ignore CPPFLAGS unless I use the preprocessor). >> Is there a standard common for all the build systems? Or some kind of >> recommendation? Or it's just a coincidence that all the build systems >> use same environment variable CFLAGS? > > CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I > believe was introduced by Autoconf, since Autoconf has historically wanted > to run tests that only use the preprocessor and not the compiler (for > checking header files, for example), at which point it needed some way of > distinguishing between the flags. GNU software and other software that > closely follows the Autoconf and Automake manuals uses a similar > separation, and it's important to follow that separation when passing > flags to configure to handle tests where just the preprocessor is run. > (If, for example, you put the -I flags in CFLAGS and not CPPFLAGS, you may > find that Autoconf probes won't find header files that are on non-standard > -I paths.) You mean, `cpp` is (was?) used only for tests done by ./configure? I was not thinking about that. Thank you for pointing that out. I just checked a few random autotools-based programs, and indeed they use $CPP variable (they actually use `gcc -E`, not `cpp` for it). > Since the Autoconf/Automake variable naming is the closest we have to a > de facto standard (and is *extremely* widespread in free software), the > variable names for the dpkg build infrastructure followed the same > conventions. It depends on whether dpkg is trying to force standards or be compatible with them. It's bad there's no some common standard or RFC about that. Since CPPFLAGS is used by ./configure only, and ./configure script is autotools-specific, it makes CPPFLAGS autotools-specific as well, and there's no reason to demand from other build systems to use it. :( And cmake is not the only one. At least mplayer's Makefile ignores CPPFLAGS (`make CPPFLAGS=-Isomedir` will work for autotools, but not for mplayer). There may be others... Another point is that the option we're talking about (-D_FORTIFY_SOURCE=2) isn't actually a preprocessor option. Preprocessor option is some option, that is supposed to affect preprocessor output. But both: cpp test.c cpp -D_FORTIFY_SOURCE=2 test.c will produce exactly same output. While these: gcc -c test.c gcc -D_FORTIFY_SOURCE=2 -c test.c will give different outputs. So despite it *looks* like a preprocessor option (-D...), it's not used by preprocessor, it's a compiler option, and belongs to CFLAGS/CXXFLAGS. So the suggestion is: if dpkg aims to be compatible with different build systems: move -D_FORTIFY_SOURCE=2 from autotools-specific CPPFLAGS to commonly used CFLAGS/CXXFLAGS where it belongs (since it's not a preprocessor option). This will fix the problem with `cmake` not using preprocessor and not checking for CPPFLAGS, make dpkg more compatible with existing build systems, and make packaging easier with no workarounds. Then we'll be able to remove a "cmake workaround" from the wiki page: http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake What do you think? Should this get filled as a bugreport? PS: Bugs must be fixed, not documented, IMO. PPS: crossposted to debian-dpkg -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOVenEotnBYauasDUn_Uv_7441kRwhfw3nT=xm7s_gm4bu0...@mail.gmail.com