bugmake - Bugs: bug #61328, elide the distinction between...

 
 

bug #61328: elide the distinction between "dir" and "dir/"

Submitted by:  David Boyce <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
Component Version:  SCM Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

( Jump to the original submission )

Tue 12 Oct 2021 01:15:21 PM UTC, comment #7: 

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.

David Boyce <boyski>
Mon 11 Oct 2021 03:06:04 PM UTC, comment #6: 

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).

Paul D. Smith <psmith>
Project Administrator
Mon 11 Oct 2021 02:51:52 PM UTC, comment #5: 

> 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?

David Boyce <boyski>
Mon 11 Oct 2021 02:43:33 PM UTC, comment #4: 

> 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?

Paul D. Smith <psmith>
Project Administrator
Mon 11 Oct 2021 02:34:49 PM UTC, comment #3: 

> 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?

Dmitry Goncharov <dgoncharov>
Mon 11 Oct 2021 01:26:58 PM UTC, comment #2: 

> 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.

David Boyce <boyski>
Sun 10 Oct 2021 11:41:12 PM UTC, comment #1: 

> 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)/

Dmitry Goncharov <dgoncharov>
Sun 10 Oct 2021 11:01:25 PM UTC, original submission:  

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.

David Boyce <boyski>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by dgoncharov (Posted a comment)
  • -email is unavailable- added by boyski (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.9