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

[David Boyce]

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

I don't think I said exactly "directories should only/always be order-only"
(so it shouldn't be in quotes), but I do think the value of this enhancement
would be primarily in order-only directory creation logic. However, if you
envision it as being always on and always applicable I certainly have no
objection.

I just wanted to get the RFE into the system for consideration. At this point
I'm happy to let it simmer for a while and see how things come out.

___

Reply to this item at:

  

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

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

[Paul D. Smith]

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:

  

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

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

[David Boyce]

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

> Why is this a concern?

I may have phrased it wrong. I just meant to bring up "a question that might
reasonably be raised" and rebut it in advance.

> Unlike other tools make doesn't really care if a prerequisite is a file or a
directory.

My understanding is that by assuming "foo/" == "foo" make would be introducing
at least a little bit of that distinction. Because while "dir" == "dir/" is
true, "file" == "file/" is false since the latter is an error at stat() time.
But maybe I'm missing something?

___

Reply to this item at:

  

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

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

[Paul D. Smith]

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

> The obvious concern is that we don't know a priori whether a target is a
directory or file.

Why is this a concern?  Unlike other tools make doesn't really care if a
prerequisite (or target) is a file or a directory.  What different behavior
could we expect to see for one versus the other?

___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

> my argument is that it can assume paths ending in the path separator are
directories since they can't be anything else:

This assumption looks reasonable.
What change in behavior do you think is appropriate with this assumption?

___

Reply to this item at:

  

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

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

[David Boyce]

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

> Do you mean that make assumes that any order-only prerequisite is a
directory and compares 'foo' as equal to 'foo/', as long as 'foo' is
order-only?

That's backward. Make should not assume O-O prereqs are directories; my
argument is that it can assume paths ending in the path separator are
directories since they can't be anything else:

$ cksum /etc/passwd/
cksum: /etc/passwd/: Not a directory

> Why don't you append a slash?

This is a category error. The entire distinction between a bug report and an
RFE is that one has a workaround and the other doesn't. I filed an RFE because
I know multiple workarounds (and showed one in the body). The focus here is
not on me and my problem but on make and how to improve it.

___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

> However, since "foo/" is illegal for anything but a directory it seems
harmless to assume directory. This special case could also be made to apply
exclusively to order-only prerequisites which is where directory dependencies
should be anyway.

It is not clear (atleast to me) what special behavior you mean. Do you mean
that make assumes that any order-only prerequisite is a directory and compares
'foo' as equal to 'foo/', as long as 'foo' is order-only?


Why don't you append a slash?


$(target): $$(@D)/


___

Reply to this item at:

  

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

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

[David Boyce]

URL:
  

 Summary: elide the distinction between "dir" and "dir/"
 Project: make
Submitted by: boyski
Submitted on: Sun 10 Oct 2021 11:01:25 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

It's documented that make implements a special case to treat pathnames
"foobar" and "./foobar" as identical even though comparisons are usually
lexical, but it does not do something similar with trailing slashes on
directory names. For instance in the test case below the target depends on its
parent directory $(@D) which comes out as "foo". We've supplied a rule for
making it but due to the behavior of the $(dir ...) function the target comes
out as "foo/" which doesn't match. This can be "fixed" with the patsubst
function but life would be more convenient and less mysterious if make
recognized them as the same.

The obvious concern is that we don't know a priori whether a target is a
directory or file. However, since "foo/" is illegal for anything but a
directory it seems harmless to assume directory. This special case could also
be made to apply exclusively to order-only prerequisites which is where
directory dependencies should be anyway.

Test case:

$ cat Makefile
.SECONDEXPANSION:

target := foo/bar

$(target): $$(@D)
touch $@

$(dir $(target)):
mkdir -p $@

$ make
make: *** No rule to make target 'foo', needed by 'foo/bar'.  Stop.

If $(dir $(target)) is wrapped as $(patsubst %/,%,$(dir $(target))) everything
works as anticipated.




___

Reply to this item at:

  

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