Re: VPATH question

[Paul Smith]

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.