Re: False positive "doesn't match the target pattern" error

[David A. Wheeler]

> On Aug 22, 2022, at 12:02 AM, Alejandro Colomar <alx.manpages@gmail.com> 
> wrote:
> 
> Hi David,
> 
> On 8/22/22 04:45, David A. Wheeler wrote:
>>> On Aug 20, 2022, at 11:35 AM, Alejandro Colomar <alx.manpages@gmail.com> 
>>> wrote:
>>> I'd say there is:  make(1) treats file names as text strings, not really 
>>> file names, for most of its operations.  As an example, foo/ and foo/. are 
>>> different targets.  I don't see why ./bar and bar should be the same.  
>>> Consistency is essential; otherwise, what to expect?  Why does make(1) need 
>>> to special-case a leading ./ ?
>> Because treating "./foo" and "foo" as different files is likely to lead to 
>> endless footguns.
>> Consistency is nice, but making something easy to use *correctly* is more 
>> important. I have no problem with special-casing "./XXX" as a synonym for 
>> "XXX"; anything else would be *unexpected* (if for no other reason than 
>> backwards compatibility).
>> As far as "foo/" vs. "foo/.", it's *much* less common to have directories as 
>> prerequisites or targets, so not handling them with special conveniences 
>> seems quite reasonable.
> 
> Is it so *much* less common?  I never really knew that make(1) treats ./foo 
> and foo as the same thing until this bug report.  make(1) is (almost) very 
> consistent in that it handles text, and not really file names.  But _all_ 
> non-phony targets should declare a dependency like '|$$(@D)/', unless you can 
> guarantee that it already exists by the time you'll try to create the file 
> (e.g., when the file depends on another file in the same dir).

> My Makefiles are plagued with that dependency, but a correctly-written 
> Makefile shouldn't even notice that ./ is trimmed.

I also try to do that, but I think it'd backwards-incompatible if GNU make 
changed its current behavior.
I suspect a lot of makefiles would quietly work incorrectly if that change was 
made.

> Do other make(1) implementations trim this leading ./?

No idea. However, I took a quick look at the POSIX make specification:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

The POSIX specification for make is notoriously underpowered.
It doesn't say anything about whether or not ./FOO is the same as FOO.
It refers to files by PRECEDING them with "./", e.g.
"By default, the following files shall be tried in sequence: ./makefile and 
./Makefile. If neither ./makefile or ./Makefile are found, other 
implementation-defined files may also be tried. [XSI]   On XSI-conformant 
systems, the additional files ./s.makefile, SCCS/s.makefile, ./s.Makefile, and 
SCCS/s.Makefile shall also be tried."
I interpret that as an expectation that adding "./" is expected to have the same
result if the filename starts with an alphabetic character, but that's
just my reading and not directly supported.

--- David A. Wheeler