Paul Smith <psm...@gnu.org> writes: > On Tue, 2016-09-20 at 15:28 +0000, Pietro wrote: >> Hi, >> >> I have noticed that there is a difference between the two scenarios >> listed below: >> >> i) make CC=arm-linux-gnueabihf-gcc CPPFLAGS=[..] >> >> ii) export CPPFLAGS=[..] [RET] >> make CC=arm-linux-gnueabihf-gcc >> >> I was told that the difference is that in the second case Make >> will append stuff to the CPPFLAGS variable exported while in the >> first case the command line argument will override the settings >> contained in the makefile itself. > > That is definitely not true. Whether or not the values here replace or > append to any value of CPPFLAGS in the makefile depends entirely on how > the variable is set in the makefile. > > GNU make has a hierarchy of precedence when it comes to how variables > are set. The weakest setting is values that are built-in to make. > Next highest is values taken from the environment. Those are > overridden by values set in the makefile itself. And finally values > set on the command line have the highest precedence. > > So if you have a makefile like this: > > CPPFLAGS = -Wall > > all: ; echo 'CPPFLAGS=$(CPPFLAGS)' > > Then if you run: > > $ CPPFLAGS=-Werror make > CPPFLAGS=-Wall > > and the makefile setting overrides the environment setting. But: > > $ make CPPFLAGS=-Werror > CPPFLAGS=-Werror > > command line settings take precedence over makefile settings. In > neither case will the value in the environment or command line be > appended to the value in the makefile: it always replaces the value. > > There are ways you can manipulate the priority, using the -e command > line option and the override specifier on variable assignment (see the > GNU make manual for this). > >> The following example, literally pasted from another thread could >> clarify the matter : >> >> var := $(shell echo "echo hi" >say_hi.sh; chmod +x say_hi.sh; >> say_hi.sh) >> all: ; @echo $(var) > > This actually just adds a lot of confusion and doesn't clarify it at > all, because (a) you're using PATH environment variable here which is > "special", at least nominally and (b) you're using $(shell ...) not > recipes, and the behavior of the shell function with respect to the > environment is different from that of recipes. This example seems to > me to be completely different than what you asked about above, such > that you can't really compare them. > >> I have posted a question at the general make mailing list and I was >> told that this might be a bug, I would love to have a clarification - >> is it a bug ? > > I think this is more a matter of you wanted to do something and you > followed a path and got stuck, so you asked about what got you stuck. > > I think you should back up and ask about what you are really trying to > do in the first place, with an example, because likely the path you > followed is not the one you want so discussing where you're stuck won't > really help. > > _______________________________________________ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make Thanks a lot, really.
I was trying to cross-compile a library and reading a forum about the library itself I have read this sentence: ------------------------------ Try this instead: CPPFLAGS=-I/home/rafael/mobi/ArmLibs/include \ LDFLAGS=-L/home/rafael/mobi/ArmLibs/lib \ make HAS_PKG_CONFIG=false CC=arm-xilinx-linux-gnueabi-gcc CXX=arm-xilinx-linux-gnueabi-g++ \ LD=arm-xilinx-linux-gnueabi-gcc LDXX=arm-xilinx-linux-gnueabi-g++ \ AR=arm-xilinx-linux-gnueabi-ar *CPPFLAGS and LDFLAGS must be defined as environment variables instead of command line arguments, as we're adding to them.* ----------------------------- At the beginning I thought there was something under the hood taking place I was not aware of, but in fact I now realize my understanding of the hierarchy of variable was ... poor: so given the rules you have explained me that is the result of how that *specific* makefile is written. When asking the same question on the general mailing list I was suggested that might be a bug that is why I posted a question here. There is not bug whatsoever :-) Thanks, P. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make