Hi Paul, Le mercredi 02 août 2017 à 15:16 -0400, Paul Smith a écrit : > On Wed, 2017-08-02 at 20:03 +0100, Sven C. Dack wrote: > > On 02/08/17 11:19, Benjamin Cama wrote: > > > Hi, > > > > > > I may be doing something wrong, but the following Makefile gives me > > > strange results: the target-specific variable does not apply when > > > used > > > for a target in a subdirectory. > > > > > > test-%: FOO = BAR > > > test-%: > > > echo $(FOO) > > > > > > E.g.: > > > > > > $ make test-stem > > > echo BAR > > > BAR > > > $ make subdir/test-stem > > > echo > > Pattern rules have a special dispensation for handling patterns with a > directory prefix, described here: > > https://www.gnu.org/software/make/manual/html_node/Pattern-Match.html > > > When the target pattern does not contain a slash (and it usually does > > not), directory names in the file names are removed from the file > > name before it is compared with the target prefix and suffix. After > > the comparison of the file name to the target pattern, the directory > > names, along with the slash that ends them, are added on to the > > prerequisite file names generated from the pattern rule’s > > prerequisite patterns and the file name. > > That's how "subdir/test-stem" can match a pattern "test-%" which you > normally would not expect it to match.
Thanks for the reference. I actually kind of expected that it would match in subdirs in my particular case, so my assumptions were wrong. During my tries to isolate the problem, I indeed stumbled upon non-pattern rules strictly matching the filenames, which then made me cautious about first wanting to report this as a “bug”, when it could have been a misinterpretation on my side, which it seems it is. > However, pattern-specific variables do not have this special > dispensation. They are simple pattern matches with no special rules > for dealing with directories. So, "subdir/test-stem" doesn't match the > pattern "test-%" for a pattern-specific variable. Ah, thanks for the explanation of the difference of behavior! This explains what I see. > It's possible that this is a mis-feature and that pattern-specific > variables should have this special capability as well, but they were > not intended to do so when originally created. You could file an > enhancement request on Savannah if you like: > > https://savannah.gnu.org/bugs/?func=additem&group=make It indeed kind of look strange that the pattern-specific feature does not work in some particular case. I do not know what would be the “right” thing to do, though; I am not sure I am skilled enough to know. Concerning my real use case, it is just to define target-specific variables for some recipes which are located in subdirectories. I am not looking for the target-specific variable feature in filenames strictly matching the target in the current directory. I looked strange that no variable was defined when in a subdirectory. 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. But then there is no difference with global variable in this case, apart from namespace pollution. I now understand that this feature is better suited to overriding a global variable in some specific recipe: is this right? To further enhance my understanding of the “right” usage of Makefiles, would you advise me to explicitly specify the subdirectory in the target definition? Because I feel that counting on pattern rules to match in subdirectory is kind of hackish, now. Like: $(SUBDIR)/target-%: … And in my particular case, I actually know the $(SUBDIR), but would it be right then to call make with: make SUBDIR=foo foo/target-1234 ? It looks redundant to me. Thanks, -- Benjamin Cama - Tél : 258 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
