Hi David, On 8/22/22 04:45, David A. Wheeler wrote:
On Aug 20, 2022, at 11:35 AM, Alejandro Colomar <alx.manpa...@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
