help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark Piffer
Subject: Re: should make elide the difference between "dir" and "dir/"?
Date: Fri, 8 Oct 2021 18:01:58 +0200

There was a discussion recently here:
https://stackoverflow.com/questions/66271761/gnu-make-wildcard-function-and-terminating-slashes-on-directory-names

Short version: GNU make doesn't implement its own globbing (using that
which the libc is providing) and thus you can't really change its behaviour
in this regard, or at least you'll pay a heavy price.

Am Fr., 8. Okt. 2021 um 17:13 Uhr schrieb David Boyce <
david.s.boyce@gmail.com>:

> 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 <mark.piffer@gmail.com> 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 <
>> david.s.boyce@gmail.com>:
>>
>>> 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.
>>>
>>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]