Re: should make elide the difference between "dir" and "dir/"?

[Steven Simpson]

Hi,

On 03/10/2021 21:50, David Boyce wrote:
> For instance in the test case below the target depends on
> its parent directory $(@D) which comes out as "foo". We've supplied a rule
> for making it but due to the behavior of the $(dir ...) function that comes
> out as "foo/" which doesn't match.
> $ cat Makefile
> .SECONDEXPANSION:
>
> target := foo/bar
>
> $(target): $$(@D)
> touch $@
>
> $(dir $(target)):
> mkdir -p $@

In any use case that boils down to this, why would you not put the mkdir 
in with the touch?

More generally, I don't really see how a directory is useful as a 
target.  Suppose you have:

foo.dir: bar.file
        mkdir -p $@

In the first case, it builds the directory.  But thereafter, the 
directory's timestamp doesn't really mean anything (as you alluded to on 
order-only prerequisites).  Whether bar.file changes or not, the mkdir 
is redundant.

If the recipe also builds the directory contents, it must build all of 
it, as any other recipe that builds part of it will set foo.dir's stamp, 
masking the need to build the rest.  If you make the rest explicitly 
depend on bar.file to avoid this, you don't need foo.dir as a target, 
because the other recipes can just mkdir it as necessary.  If the recipe 
builds all of the contents, you can make the last file updated be the 
target instead of the directory.

If you're building a large directory structure for zipping up, and some 
empty directories are required, there should be a target (perhaps empty) 
for the directory structure as a whole, and the mkdirs can go there.  Or 
you could create dummy files that are excluded from the zip.  Or put the 
mkdirs in with the zip.

Perhaps there's a better use case…?

Cheers,

Steven