> On Aug 22, 2022, at 12:02 AM, Alejandro Colomar <alx.manpa...@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.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.
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
