Re: VPATH question
On Fri, 2023-02-24 at 17:40 +0100, Gisle Vanem wrote: > Paul Smith wrote: > > If you use "-d" you'll get the info you want: > > > > No implicit rule found for 'default'. > > Considering target file 'lib'. > > Finished prerequisites of target file 'lib'. > > No need to remake target 'lib'; using VPATH name 'apps/lib'. > > Finished prerequisites of target file 'default'. > > > > > Only adding 'MAKEFLAGS += --warn-undefined-variables' is somewhat > > > helpful. > > > > You should feel free to do that, if your makefiles are written such > > that it doesn't give spurious warnings. Make has silently expanded > > empty variables to the empty string for 40 years and changing that > > as the default behavior is not an option. > > Ok thanks for the explanation. But I tend to use 'vpath %.c dir' > more and more. It seems a lot faster too. In my opinion it's just not a good idea to use directories as prerequisites in makefile rules, period, with only very specific, limited exceptions. But, I realize that I'm in the distinct minority in this opinion and that all the "hot new makefiles" tend to do this. I'll stick to my old fuddy-duddy opinions however. Keep those directories off my lawn! As for "it seems a lot faster", I have no comment since you don't say what it seems faster than. If you mean that "vpath %.c dir" is faster than "VPATH = dir", then that's not surprising since the latter searches "dir" for every single prerequisite while the former only searches for prerequisites that match the pattern. If you mean it's faster than listing the full pathname explicitly as a prerequisite, then I can't believe that's the case. Cheers!
Re: VPATH question
Paul Smith wrote: If you use "-d" you'll get the info you want: No implicit rule found for 'default'. Considering target file 'lib'. Finished prerequisites of target file 'lib'. No need to remake target 'lib'; using VPATH name 'apps/lib'. Finished prerequisites of target file 'default'. Only adding 'MAKEFLAGS += --warn-undefined-variables' is somewhat helpful. You should feel free to do that, if your makefiles are written such that it doesn't give spurious warnings. Make has silently expanded empty variables to the empty string for 40 years and changing that as the default behavior is not an option. Ok thanks for the explanation. But I tend to use 'vpath %.c dir' more and more. It seems a lot faster too. -- --gv
Re: VPATH question
On Fri, 2023-02-24 at 08:44 +0100, Gisle Vanem wrote: > So I want to create a './lib' directory in > 'Current Directory', but gnumake won't do it > since there is a 'lib' under 'apps'. Output: > gnumake: Nothing to be done for 'default'. > > Why doesn't it understand the meaning of '.'? It does. Make adds the prerequisite to every VPATH entry. Your VPATH entry is "apps" and the prerequisite is "./lib", and so the combination is "apps/./lib" which is a perfectly legal pathname, that is found. > It also drops the '.' in the --debug' output. This is due to a special rule in GNU make that allows "." to be ignored for the purposes of target matching. It's a little obscure, but it's not related to the issue you're having with VPATH. Even if it kept the "./", "apps/./lib" would still exist and be matched. > Besides I feel it's not very helpful explaining why > it won't do "Nothing..". E.g. if I make a typo: >default all: $(GEN_DIRS2) > > it's the same bleeding message. Well, I'm not sure it's useful for make to generate one message for situations where a target is not rebuilt because all of its N prerequisites are up to date and N > 0, and a different message for the special case where N == 0. > Adding a '--debug=w', > would be nice with a 'why not' message. If you use "-d" you'll get the info you want: No implicit rule found for 'default'. Considering target file 'lib'. Finished prerequisites of target file 'lib'. No need to remake target 'lib'; using VPATH name 'apps/lib'. Finished prerequisites of target file 'default'. > Only adding 'MAKEFLAGS += --warn-undefined-variables' is somewhat > helpful. You should feel free to do that, if your makefiles are written such that it doesn't give spurious warnings. Make has silently expanded empty variables to the empty string for 40 years and changing that as the default behavior is not an option.
