Re: [PATCH] More correctly describe the scope of variables

[Jouke Witteveen]

On Fri, Dec 25, 2020 at 7:00 PM Jouke Witteveen  wrote:
>
> * NEWS: Use "local" instead of the incorrect "lexically-scoped".
> * doc/make.texi: Refer to let/foreach variables as local variables.
> ---
> This is an erratum on the addition of $(let ...). During an early review
> of $(let ...), thutt cautioned that it did not implement "full semantic
> scoping" [sic]. While I did not understand fully what they meant by
> that, I countered that it was not intended to determine a scope based on
> for example which file a definition of a rule occurred in, but simply by
> the parentheses delimiting the let expression. Only in that sense was it
> lexical scoping. Technically, make variables are dynamically scoped.
>
> This patch replaces "lexically scoped" not by "dynamically scoped", but
> by "local", since that is the whole point after all. It also includes
> variables with local scope (from let and foreach) in several other
> places where variables are discussed, and makes explicit that variables
> in make are dynamically scoped.

I think this is ready to go in and that it would be wise to not
release with the unchanged NEWS.
Was this patch simply missed due to end-of-year activities?

Regards,
- Jouke

Re: Time for a new release...

[Paul Smith]

On Sun, 2020-12-20 at 14:19 -0900, Britton Kerin wrote:
> A while back there was talk about making Make a bit smarter about
> understanding implicit dependencies make-sphere stuff:
> 
> http://gnu-make.2324884.n4.nabble.com/Idea-Add-COMMANDCHANGE-and-CACHE-td19133.html
> 
> I've come to like the idea and am curious if anything ever happened
> on this?

No, no one ever pushed that further as far as I know.  As a concept
it's not bad: similar to some things I've been thinking of although I
was thinking of using symlinks to avoid file reads... I'm not a fan of
using directories because some filesystems have limits on the number of
subdirectories.  I'm also not sure about using SHA for this; do we
really need the expense of a cryptographic hash here?  Don't we really
mostly care about uniqueness?  But these are just implementation
details.

The main thing is that once you create a concept of a "make durable
state" then there are a lot of things that you might like to have
there.  That proposal discusses the SHA of a command line, to detect
when compiler options change for example.

But, there have been other things people have wanted durable state for:
for example basing out-of-date detection on things like file content or
other attributes besides mod time.

And there are probably other things that will come up.

It seems like a not-great idea to have multiple ways of storing durable
state, so the question is can we come up with a method flexible enough
that we won't be banging our heads against it in a year.

Re: Time for a new release...

[Paul Smith]

On Sun, 2020-12-20 at 18:09 -0500, Paul Smith wrote:
> I'm thinking of putting out a new release of GNU make early in the
> new year.

Hi all; just an update on this:

The company I work for was acquired, so I need to redo my disclaimer
with my new benevolent overlords.  I've done this many times and it's
always been fine, but getting the piece of paper on the right desk can
sometimes take a bit of time, especially during the bustle of an
acquisition.

Out of an abundance of caution I will be slow-rolling changes until
this is complete.  I see no reason to expect it will take very long.

Cheers!

Re: GNU Make documentation example error

[Martin Dorey]

Looks like the report in:

https://lists.gnu.org/archive/html/bug-make/2021-01/msg00016.html

... only this time without any version number.  The answer a couple of weeks 
ago was:

https://lists.gnu.org/archive/html/bug-make/2021-01/msg00017.html

(I couldn't find it with Google, even though I remembered it, though I failed 
to find a robots.txt preventing it from indexing the mailing list archive.)


From: Bug-make  on behalf of 
Niko's ProtonMail Account 
Sent: Thursday, January 28, 2021 04:34
To: bug-make@gnu.org 
Subject: GNU Make documentation example error

* EXTERNAL EMAIL *

Dear GNU maintainers,

I think there may be a mistake in the section “5.8 Defining Canned Recipes” of 
the GNU Make manual: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Fsoftware%2Fmake%2Fmanual%2Fmake.html%23Canned-Recipesdata=04%7C01%7CMartin.Dorey%40hitachivantara.com%7Cb6e93aa4053748e460a808d8c39fbcce%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637474438130704342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3x9RGtb5xiMwT%2FA%2BdiEP6ay%2FXyHMHSa9I8%2Fg4NYvyCM%3Dreserved=0.
The examples show the “define” directive followed by an equals sign (“=“), 
however for me it only works once I remove the equals sign as shown in the 
section on defining multi-line variables: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Fsoftware%2Fmake%2Fmanual%2Fmake.html%23Multi_002dLinedata=04%7C01%7CMartin.Dorey%40hitachivantara.com%7Cb6e93aa4053748e460a808d8c39fbcce%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637474438130704342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5KRsO6siDx5U%2FgkcYXXxhG6%2BAoJE%2F3xiwdFs%2F%2FfJp0M%3Dreserved=0.
Interestingly, even that section contains an example where the equals sign is 
used (at the bottom of the section) and it likewise only works once I remove 
the equals sign.

Best,
Nikolai

GNU Make documentation example error

[Niko's ProtonMail Account]

Dear GNU maintainers,

I think there may be a mistake in the section “5.8 Defining Canned Recipes” of 
the GNU Make manual: 
https://www.gnu.org/software/make/manual/make.html#Canned-Recipes.
The examples show the “define” directive followed by an equals sign (“=“), 
however for me it only works once I remove the equals sign as shown in the 
section on defining multi-line variables: 
https://www.gnu.org/software/make/manual/make.html#Multi_002dLine.
Interestingly, even that section contains an example where the equals sign is 
used (at the bottom of the section) and it likewise only works once I remove 
the equals sign.

Best,
Nikolai

[bug #59956] Recipes inside conditionals can break the parser

[Dmitry Goncharov]

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

i mean, the user would tell make through some option (a special target or even
presence of ".else" in the makefile) "this makefile uses .else, rather then
else". make then would not consider "else" a keyword.
The keyword does not have to be ".else". It could be e.g. "otherwise". With
"otherwise" there is no need to prefix all conditionals with a ".".


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

Re: [bug #59956] Recipes inside conditionals can break the parser

[Edward Welbourne]

> Consider the following example:

> ifeq (1,0)
> test:
> @if [ "asd" == "123" ]; then
> echo "true"
> else
> echo "false"
> fi
> endif

> The *else* recipe at line 5 is treated as part of the *ifeq (1,0)*
> conditional thus making the next recipe line fail because there is no
> target before it:

> Makefile:6: *** recipe commences before first target.  Stop.

... and this could all too easily go *unreported* if this conditional
target-and-rule appeared just after some other.

I expected it to lead to the resulting rule getting a syntax error, but
am now baffled to find, by experiment, that (with suitable blocks of
spaces replaced by tabs, of course, if my mailer has substituted spaces
for tabs, which it probably has)

.ONESHELL:

fluff:
@echo fluff

ifeq (1,0)
test:
@if [ "asd" == "123" ]; then
echo "true"
else
echo "false"
fi
endif

echo puff

doesn't provoke an error; make fluff simply echoes fluff then puff,
without echoing false or complaining of a syntax error due to the fi.
Removing the tab before else does get me the expected syntax error, so I
think something more complicated is going on here than simply the else
being recognised as belonging to the ifeq.

Can anyone explain that ?

> _I know the recipe does not make any sense without .ONESHELL, but it
> should not matter. Maybe the user has a shell with a valid "else"
> command.

That has proven a fascinating topic, thanks for bringing it up.
I particularly liked Paul's example of how adding a .PHONY rule could
dramatically change the meaning of a Makefile that uses tabs to indent
things not intended as rules.  One more reason to *only* use tabs in
rules.

The error message isn't much help, even when you do get it, but once
you've worked out what the problem there is at least a straightforward
work-around for the case above; just (regardless of .ONESHELL being set)
backslash-escape relevant newlines (and add semicolons before them,
where needed),

ifeq (1,0)
test:
@if [ "asd" == "123" ]; then \
echo "true"; \
else \
echo "false"; \
fi
endif

so that make sees the rule all as one line and the else doesn't appear
(as far as make is concerned) as a line on its own.

Eddy.