On Tue, Jan 14, 2014 at 06:29:48PM +0000, Beckett, Robert wrote: > In Makefile language, rule and dependency definitions use immediate > expansions of variables, so they get expanded as soon as the rule is > created (1st pass). Rule implementation (a.k.a recipe) use deferred > expansion (2nd pass). I had forgotten that the rules are expanded in the first pass, makes it clear. Thanks. Pushed, with this blob attached and a direct link the "how make reads a Makefile section", that makes a much better commit message! -- Damien > > Android effectively makes all Android.mk files a single makefile by > including them all in a big tree from the toplevel makefile. The rules > are all evaluated in the first pass and targets are generated. Then > the 2nd pass happens and the required target's recipes are run. At > this point, LOCAL_PATH has been assigned the value from the last > evaluated Android.mk in the 1st phase that defined LOCAL_PATH (most > Android.mk use this variable). In my particular case, it was the > bootloader's Android.mk that was evaluated last and had defined > LOCAL_PATH to it's path. The errors are rather misleading due to it > looking like a bug in another module's Android.mk rather than this one > :) > > Basically, if you want to use a variable that any other Android.mk > defines, then you can only use it in an immediate expansion context, > not a deferred expansion context as it will likely be re-defined by > the time the 2nd pass happens. > > This patch stores it in a unique variable that should not be being > used by other Android.mk files. An alternative fix would be to use $@ > and $< as the files in question are target and dependency, but I never > like using those as they can easily break if dependencies are added > etc. I prefer variable to be explicitly named to make them obvious. > > (see gnu make manual for explanation of deferred vs immediate > expansion of variables : > http://www.gnu.org/software/make/manual/make.html ) _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
