bug-make
[Top][All Lists]
Advanced

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

[bug #61328] elide the distinction between "dir" and "dir/"


From: Paul D. Smith
Subject: [bug #61328] elide the distinction between "dir" and "dir/"
Date: Mon, 11 Oct 2021 11:06:04 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

Follow-up Comment #6, bug #61328 (project make):

Well, make isn't doing any stat: it's just comparing text.  And in fact, it
can't use stat because there's an excellent chance that the filesystem object
being discussed doesn't even exist yet.

I guess I'm a little confused as to what the concern is WRT this paragraph.

The backward-compatibility issue I could imagine is something like, some
makefile is defining rules for both "dir" and "dir/" and using "dir" as
prerequisites in some rules and "dir/" as prerequisites in other rules, and
expecting them to be treated as completely separate targets... but which map
to the same underlying file (or directory).

I have a hard time envisioning what a use-case would be for that however.

I am not interested in having this special case apply only to certain types of
prerequisites such as order-only prerequisites.  I also don't want to add some
kind of special flag to control this: it's just as simple to use a workaround
as to enable the special flag.  It should either just be always on, or always
off, IMO.  If we think the backward-compatibility problems are to severe then
I don't think we should do it.

I also actually don't agree that "directories should only/always be
order-only".  There are in fact good reasons to list directories as regular
prerequisites of a target... they are just not the reasons most people do it. 
It can be very useful to use directories as prerequisites if you intend to
take advantage of their particular time-last-modified rules (that the
directory is "updated" whenever any file is created, deleted, or renamed in
that directory).

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61328>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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