Le jeudi 03 août 2017 à 09:20 -0400, Kyle Rose a écrit : > On Aug 3, 2017 9:00 AM, "Benjamin Cama" <b.c...@kerlink.fr> wrote: > Anyway, it seems that a global variable would solve my problem, and > indeed it looks a bit more right this way: I can still get the stem in > my recipe (with $*), and everything works as expected. It's just that > the global namespace is “polluted” by this variable which is used only > in my particular recipe. And this is where I may be mistaken on the > use > of target-specific variable: I tend to use them as a kind of “private > namespace” feature, when I define something that will be used only in > one particular recipe. > > > What we do in our makefiles is to use global variable names containing > paths. E.g., > > > subdir/FOO = bar
Thanks for the tip, this looks very useful. Even if in my case, the subdir is dynamic, but I can prefix the variables with some name specific to my recipe. > You can modularize this via some construction like: > > > M := subdir > ... > $M/FOO = bar Nice. I see this is also used in OpenWrt, which is my reference for advanced Makefile usage. > Make doesn't provide a lot of structure for encapsulation (there are > no objects or directly-addressable structures, for instance), but it > does give you enough flexibility to create something manageable. Yes, and I like that it just gives enough, but is not plagued by feature-creep. Thanks. -- Benjamin Cama - Tél : 258 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
