Thanks but just to be clear(er), I'm not looking for help solving a problem of my own, just suggesting that it might make sense for GNU make to ignore a trailing "/" when comparing directory names just as it already ignores a leading "./".
Thanks for the pointer to the library, though. Looks like lots of good stuff. David On Fri, Oct 8, 2021 at 1:43 AM Mark Piffer <[email protected]> wrote: > The GNUmake table toolkit has an extension to the wildcard function, maybe > this could help you: > https://github.com/markpiffer/gmtt#call-wildcard-reclist-of-globs > > > Am So., 3. Okt. 2021 um 22:51 Uhr schrieb David Boyce < > [email protected]>: > >> It's documented that make implements a special case to treat pathnames >> "foobar" and "./foobar" as identical even though comparisons are usually >> lexical, but I notice that it doesn't do the same with trailing slashes on >> directory names. 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. This can be "fixed" with the patsubst >> function but life would be more convenient and less mysterious if make >> recognized them as the same. Has this been considered in the past? >> >> The obvious concern is that we don't know a priori whether a target is a >> directory or file. However, since "foo/" is illegal for anything but a >> directory it seems harmless to assume directory. This matching could also >> be made to apply exclusively to order-only prerequisites which is where >> directories should be anyway. >> >> David >> >> $ cat Makefile >> .SECONDEXPANSION: >> >> target := foo/bar >> >> $(target): $$(@D) >> touch $@ >> >> $(dir $(target)): >> mkdir -p $@ >> >> $ make >> make: *** No rule to make target 'foo', needed by 'foo/bar'. Stop. >> >
