[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

URL:
  

 Summary: Normalize foo/./bar
 Project: make
   Submitter: 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
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 21 Aug 2022 03:38:36 AM UTC By: Dmitry Goncharov 
.








___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

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

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


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

Additional Item Attachment, bug #62929 (project make):

File name: sv62929_fix.diff   Size:3 KB


File name: sv62929_test.diff  Size:1 KB




___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

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

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.



___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

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

pmake behaves the same as bmake.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

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

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


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Rex Yuan]

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

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.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Paul D. Smith]

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

Thanks Rex.  If you prefer you can also send an email to the bug-make@gnu.org
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!


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Rex Yuan]

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

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.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Rex Yuan]

Follow-up Comment #8, bug #62929 (project make):

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.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Paul D. Smith]

Follow-up Comment #9, bug #62929 (project make):

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.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Rex Yuan]

Follow-up Comment #10, bug #62929 (project make):

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.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Paul D. Smith]

Follow-up Comment #11, bug #62929 (project make):

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.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[anonymous]

Follow-up Comment #12, bug #62929 (project make):

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.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Paul D. Smith]

Follow-up Comment #13, bug #62929 (project make):

Good idea.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Rex Yuan]

Follow-up Comment #14, bug #62929 (project make):

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


___

Reply to this item at:

  

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