bugmake - Bugs: bug #62929, Normalize foo/./bar

 
 

bug #62929: Normalize foo/./bar

Submitter:  Dmitry Goncharov <dgoncharov>
Submitted:  Sun 21 Aug 2022 03:38:36 AM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.4 Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 11 Sep 2022 07:42:44 PM UTC, comment #14: 

Thanks for digging this part of the manual up.

> There are two exceptions: a target starting with a period is not a default unless it contains one or more slashes, ‘/’, as well;


I attempt to express this precisely in a somewhat informal modal logic form:

  1. start_with_period(target) & !contains_slashes(target) => !possible[default(target)]
  2. start_with_period(target) & contains_slashes(target) => possible[default(target)]
  3. possible[default(target)] & is_first(target) => default(target)


While this exception does explain the behavior of the examples I provided in the comment before, I don't think it explains that of this Makefile:


.a:
        $(info 0)

./.b: # skip
        $(info 1)

c: # choose
        $(info 2)


  1. './.b' starts with a '.'; start_with_period('./.b') holds
  2. './.b' contains one or more '/'; contains_slashes('./.b') holds


It follows that './.b' should be default. Yet, 'c' is chosen.


$ make -p | grep DEFAULT_GOAL
.DEFAULT_GOAL := c
$ ./makebin/make-4.3/make -p | grep DEFAULT_GOAL
.DEFAULT_GOAL := c





Another thing I'd like to add is that there is another parenthetical mention that should probably be clarified. It is that in the index entry of .DEFAULT_GOAL, the linked 6.14 Other Special Variables item which in turn links 9.2 Arguments to Specify the Goals it says:

> By default, the goal is the first target in the makefile (not counting targets that start with a period).

Rex Yuan <rex>
Sun 11 Sep 2022 07:08:10 PM UTC, comment #13: 

Good idea.

Paul D. Smith <psmith>
Group administrator
Sun 11 Sep 2022 07:02:24 PM UTC, comment #12: 

Couldn't the 2nd and 3rd sentences be simplified as:

The default goal is the first target of the first rule in the first makefile.

Anonymous
Sun 11 Sep 2022 06:36:29 PM UTC, comment #11: 

This information is in the manual, in another section "Writing Rules"

https://www.gnu.org/software/make/manual/html_node/Rules.html

> The order of rules is not significant, except for determining the default goal: the target for make to consider, if you do not otherwise specify one. The default goal is the target of the first rule in the first makefile. If the first rule has multiple targets, only the first target is taken as the default. There are two exceptions: a target starting with a period is not a default unless it contains one or more slashes, ‘/’, as well; and, a target that defines a pattern rule has no effect on the default goal.


However this parenthetical mention should be clarified as well.

Paul D. Smith <psmith>
Group administrator
Sun 11 Sep 2022 05:58:33 PM UTC, comment #10: 

I understand now. In that case, I will start learning how to properly contribute to this project and try to come up with some proper edits to the manual that clarifies things, or maybe we could simply tell people not to use dot for relative pathing as it may lead to undefined behavior.

Thank you for your prompt response. Hopefully I can contribute more to Make project in the future. By the way, I'm super glad your blog is back up again; I referenced it a lot when I gave tutorials on Make.

Rex Yuan <rex>
Sun 11 Sep 2022 05:42:59 PM UTC, comment #9: 

I see.  That comment in the manual only applies to targets that start with "." as part of a simple name, it doesn't apply to targets that contain "." as part of a pathname.

Basically, if the target contains a directory separator it cannot be "special" in this way.

This special case is not meant to treat hidden files (as defined by POSIX) specially at all.  It's meant to apply to special targets like .POSIX:, .SECONDEXPANSION, .NOTPARALLEL, etc., that are not files, or any similar targets that the user might want to create.

That should be stated clearly in the manual, for sure.

Paul D. Smith <psmith>
Group administrator
Sun 11 Sep 2022 05:35:29 PM UTC, comment #8: 

Might I add on the last comment, as I can't find an edit button.

I think: if the intention of not using dot-leading targets as default goal is to ignore hidden file targets when looking for default goal, then the behavior of treating target './b' as 'b' is correct; it's just that the manual didn't spell out this intention so it is confusing what exactly are ignored; everything syntactically matching? or there's some semantic intention here. On the other hand, the target '...../b' should be treated as a 'b' file under directory '.....' and thus is not a hidden file so this behavior is also correct.

Rex Yuan <rex>
Sun 11 Sep 2022 05:19:40 PM UTC, comment #7: 

Thank you Paul for walking me through the means of participation.

Following is what I should've quoted, from 2.3 How make Processes a Makefile.

> By default, make starts with the first target (not targets whose names start with ‘.’). This is called the default goal.


I interpret this as that Make sets the default goal as the first target encountered without containing the prefix '.'. Thus, considering both of my examples, Make should, in both cases, have chosen 'c' as default goal since the other two both start with '.'.

If I may express my opinion a little bit: I think there is a lack of treatment in the manual on how exactly relative pathing with dots are dealt with in writing targets and matching goals.

Rex Yuan <rex>
Sun 11 Sep 2022 04:43:04 PM UTC, comment #6: 

Thanks Rex.  If you prefer you can also send an email to the -email is unavailable- mailing list (no subscription required).  Also you can comment on issues in Savannah anonymously (you don't have to create an account) although you obviously won't get notified of updates, unless you add yourself as a watcher to the issue (see the "Mail Notification Carbon-Copy List" box at the bottom).

However, I'm not exactly sure what the issue is.  You say which deviates from what the manual suggests but you don't quote the manual's suggestion and you don't specify exactly what the deviation is (that is, what you expected the result to be).

Cheers!

Paul D. Smith <psmith>
Group administrator
Sun 11 Sep 2022 04:32:09 PM UTC, comment #5: 

Apologies if this isn't the place but I thought I ran into a relevant problem as it also pertains to how Make deals with '.' in targets.

For Makefile:

.a:
        $(info 0)

./b:
        $(info 1)

c:
        $(info 2)

Running either Make 3.81 that comes with my machine or the compiled Make 4.3 from the FTP server, Make sets 'b' for .DEFAULT_GOAL according to running with option '-p', which deviates from what the manual suggests.

It also seems the same if we replace './b' with however many leading dots such as '...../b', but printing data base suggests it's another stranger case. For Makefile:

.a:
        $(info 0)

...../b:
        $(info 1)

c:
        $(info 2)

Either version of Make sets '...../b' for .DEFAULT_GOAL. I assume it means that Make knows the dots aren't there for relative paths but it chooses it still.

Again I'm sorry if this is irrelevant. I've never participated in GNU projects before and just spent half an hour figuring out how to comment.

Rex Yuan <rex>
Tue 23 Aug 2022 02:45:34 AM UTC, comment #4: 

Given makefile
foo/bar:; @echo $@

and target foo/./bar this changeset sets $@ to foo/bar.

To proceed with this, changes may be needed in addition to the one in the attachment.
1. same normalization in lookup_file and in main
2. ability to match foo/./bar rule to foo/bar target

Dmitry Goncharov <dgoncharov>
Tue 23 Aug 2022 02:29:02 AM UTC, comment #3: 

pmake behaves the same as bmake.

Dmitry Goncharov <dgoncharov>
Tue 23 Aug 2022 01:32:26 AM UTC, comment #2: 

i compared gmake, bmake, sun make, sun dmake, sun make in svr4 mode, aix make.

Given makefile
hello:
    @echo $@

gmake treats ./hello, ././hello, ././/hello or .//hello, as hello. $@ has value hello.
sun make, sun dmake, sun svr4 make treat ./hello, ././hello or ././/hello as hello. $@ has value hello.

Sun make, sun dmake and sun svr4 make all treat .//hello or .//.///.///hello as /hello. This is clearly a bug in sun make, dmake and svr4 make.

bmake, aix make treat ./hello, ././hello, ././/hello or .//hello as different from hello.

Given makefile
foo/bar:
    @echo $@

sun make, sun dmake, sun svr4 make treat foo/./bar, foo/././bar or foo//.//.//bar as foo/bar. $@ has v alue foo/bar.
gmake, bmake, aix make all treat foo/./bar, foo/././bar or foo//.//.//bar as different from foo/bar.


Given makefile
./hello:
    @echo $@

sun make, sun dmake, sun svr4 make all use ./hello rule to build hello ././hello or ././/hello and $@ has value hello.
With this makefile gmake can build ./hello, ././hello or .//.//.//hello and $@ has the value hello.
With this makefile gmake fails to build hello.

bmake, aix make build ./hello and nothing else and $@ has value ./hello.

Given makefile
foo/./bar:
    @echo $@

sun make, sun dmake, sun svr4 make all use rule foo/./bar to build foo/bar, foo/./bar and foo//.//.//bar and $@ has value foo/bar.

With this makefile gmake can build foo/./bar and nothing else and $@ has value foo/./bar.
bmake, aix make build foo/./bar and nothing else and $@ has value foo/./bar.

Dmitry Goncharov <dgoncharov>
Sun 21 Aug 2022 03:43:45 AM UTC, comment #1: 

Make fails to normalize foo/./bar as foo/bar.

The original bug report is here
https://lists.gnu.org/archive/html/bug-make/2022-08/msg00064.html

Dmitry Goncharov <dgoncharov>
Sun 21 Aug 2022 03:38:36 AM UTC, original submission:  

.

Dmitry Goncharov <dgoncharov>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #53590:  sv62929_fix.diff added by dgoncharov (3KiB - text/x-patch)
file #53591:  sv62929_test.diff added by dgoncharov (2KiB - text/x-patch)

 

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 rex (Posted a comment)
  • -email is unavailable- added by dgoncharov (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.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-08-21 dgoncharov Attached File- Added sv62929_fix.diff, #53590
        Attached File- Added sv62929_test.diff, #53591

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code