[bug #62929] Normalize foo/./bar

2022-09-11 Thread 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/




[bug #62929] Normalize foo/./bar

2022-09-11 Thread 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

2022-09-11 Thread 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

2022-09-11 Thread 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

2022-09-11 Thread 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/