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

[Alejandro Colomar]

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.

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

Cheers,

Alex

> --- David A. Wheeler

--
Alejandro Colomar
<http://www.alejandro-colomar.es/>

OpenPGP_signature
Description: OpenPGP digital signature