feature requests: $(__FILE__) and $(__LINE__) textual macros

[Basile Starynkevitch]

Hello

For non-trivial GNUmakefile-s on Linux it would be nice to have a 
$(__FILE__) and $(__LINE__) textual macros of GNU make.


They would behave as their equivalent __FILE__ and __LINE__ of the Cpp 
preprocessor.


On Linux Debian trixie/sid x86-64, my GNU make is
% /usr/bin/make --version
GNU Make 4.3
Built for x86_64-pc-linux-gnu

I do have a buggy non-trivial GNUmakefile
in 
https://github.com/RefPerSys/RefPerSys/blob/6f133cdfe044d652b394b7402f020d976336d72f/GNUmakefile


FYI, RefPerSys on https://github.com/RefPerSys/RefPerSys/ is a GPLv3+ 
licensed inference engine project. RefPerSys meaning "reflective 
persistent system".


Your opinion is appreciated on this new feature requests.

Regards from near Paris in France.


--
Basile Starynkevitch 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
See https://github.com/RefPerSys/RefPerSys

Re: feature requests: $(__FILE__) and $(__LINE__) textual macros

[Paul Smith]

On Sat, 2024-01-27 at 18:06 +0100, Basile Starynkevitch wrote:
> For non-trivial GNUmakefile-s on Linux it would be nice to have a 
> $(__FILE__) and $(__LINE__) textual macros of GNU make.

It would be great if you could provide examples where these would be
useful, especially examples that are not already covered by the output
of the -p option to GNU Make.

I'm not saying we shouldn't introduce these, although I think you
misunderstand how tricky it would be to use them (for example, if you
set:

FOO = $(__LINE__)

BAR := $(FOO)

then will BAR get line number 3, where the variable reference $(FOO) is
expanded, or the line number 1, where the variable FOO is defined?) 
But we need to understand the use-cases to evaluate the request.

-- 
Paul D. Smith Find some GNU make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: feature requests: $(__FILE__) and $(__LINE__) textual macros

[Basile Starynkevitch]

On 1/27/24 20:11, Paul Smith wrote:

On Sat, 2024-01-27 at 18:06 +0100, Basile Starynkevitch wrote:

For non-trivial GNUmakefile-s on Linux it would be nice to have a
$(__FILE__) and $(__LINE__) textual macros of GNU make.


It would be great if you could provide examples where these would be
useful, especially examples that are not already covered by the output
of the -p option to GNU Make.


make -p don't show (unfortunately) the line number in makefiles. 
Alternatively, a runtime option for make -p (perhaps 
--show-line-numbers) would be nice.


I'm not saying we shouldn't introduce these, although I think you
misunderstand how tricky it would be to use them (for example, if you
set:

 FOO = $(__LINE__)


This would be expanded at Makefile parsing time. Not at function 
invocation time.


If I started to implement it, I would add

  FT_ENTRY ("__LINE__",   0,  0,  0,  func__LINE__),

in GNU make's  src/function.c file.


and probably func__LINE__ would return some ebuf->floc.lineno


For
  FT_ENTRY ("__FILE__",   0,  0,  0,  func__FILE__),

I guess func__FILE__ would return some ebuf->floc.filenm

So my intuition is that this feature is easy to implement.

Sorry, English is not my native language, but I was thinking of 
$(__FILE__) and $(__LINE__) being implemented as close as possible to 
the GNU make parsing code.


Thanks for your email.

Regards
--
Basile Starynkevitch 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
See https://github.com/RefPerSys/RefPerSys

Re: feature requests: $(__FILE__) and $(__LINE__) textual macros

[Basile Starynkevitch]

On 1/27/24 20:27, Basile Starynkevitch wrote:



On 1/27/24 20:11, Paul Smith wrote:

On Sat, 2024-01-27 at 18:06 +0100, Basile Starynkevitch wrote:

For non-trivial GNUmakefile-s on Linux it would be nice to have a
$(__FILE__) and $(__LINE__) textual macros of GNU make.


It would be great if you could provide examples where these would be
useful, especially examples that are not already covered by the output
of the -p option to GNU Make.


make -p don't show (unfortunately) the line number in makefiles. 
Alternatively, a runtime option for make -p (perhaps 
--show-line-numbers) would be nice.


I'm not saying we shouldn't introduce these, although I think you
misunderstand how tricky it would be to use them (for example, if you
set:

 FOO = $(__LINE__)


This would be expanded at Makefile parsing time. Not at function 
invocation time.


If I started to implement it, I would add

   FT_ENTRY ("__LINE__",   0,  0,  0,  func__LINE__),

in GNU make's  src/function.c file.


and probably func__LINE__ would return some ebuf->floc.lineno


[...]

The issue is of course to find the relation between ebuf (which is a 
local parameter in GNU make source read.c) and the functions in 
function.c


My guess is that since GNU make is itself a serial (non-threaded) 
program, that relation should be simple to find.


Should I have to find it, I would use gdb breakpoint facilities.

Thanks for reading.

Regards.

NB I might perhaps implement such a feature if (and only if) I don't 
have any copyright assigment to find. In my GCC contributing experience 
fifteen years ago, that administrative step was really painful. I am too 
old to start such nightmares again.


--
Basile Starynkevitch 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
See https://github.com/RefPerSys/RefPerSys

Re: feature requests: $(__FILE__) and $(__LINE__) textual macros

[Paul Smith]

On Sat, 2024-01-27 at 20:27 +0100, Basile Starynkevitch wrote:
> > It would be great if you could provide examples where these would
> > be
> > useful, especially examples that are not already covered by the
> > output
> > of the -p option to GNU Make.
> 
> make -p don't show (unfortunately) the line number in makefiles. 
> Alternatively, a runtime option for make -p (perhaps 
> --show-line-numbers) would be nice.

It definitely DOES show line numbers.  For example for a variable
definition:

  # makefile (from 'Makefile', line 361)
  PACKAGE_NAME = GNU Make

and for a rule definition:

  all: alloca.h
  #   ...
  #  recipe to execute (from 'Makefile', line 490):
  $(MAKE) $(AM_MAKEFLAGS) all-recursive

> > I'm not saying we shouldn't introduce these, although I think you
> > misunderstand how tricky it would be to use them (for example, if
> > you set:
> > 
> >   FOO = $(__LINE__)
> 
> This would be expanded at Makefile parsing time. Not at function 
> invocation time.

I'm not sure what you mean by "this".  It would be helpful to my
understanding if you used the example I provided and showed what value
you expected BAR to have: 1 or 3?  Then I could be sure I understood
what you meant.

Macros and functions in recursive variable assignments ("=") are not
expanded when the variable is defined.  They are expanded when the
variable is referenced.  For example if you have:

   bar = 1
   FOO = $(bar)
   bar = 2
   all: ; @echo $(FOO)

then the output will be "2", not "1", because $(bar) is not expanded
when FOO is defined, it's expanded when $(FOO) is expanded (in the
recipe, in this example).

Are you suggesting that $(__LINE__) would somehow be a special case and
NOT work like this?  So if I have:

  bar = 1
  FOO = $(bar) $(__LINE__)
  bar = 2
  all: ; @echo $(FOO)

the output I got would be "2 2" instead of "2 4"?

In other words, make would parse the value of FOO looking for
references to the special variables __LINE__ and __FILE__ and expand
only those, but not other macros or functions?

> If I started to implement it, I would add
> 
>    FT_ENTRY ("__LINE__",   0,  0,  0,  func__LINE__),
> 
> in GNU make's  src/function.c file.

This would almost certainly not do what you want.

> So my intuition is that this feature is easy to implement.

I don't think you're correct about that.  But any discussion of the
implementation details is premature: the behavior must be defined
first.

-- 
Paul D. Smith Find some GNU make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: feature requests: $(__FILE__) and $(__LINE__) textual macros

[Paul Smith]

On Sat, 2024-01-27 at 20:45 +0100, Basile Starynkevitch wrote:
> NB I might perhaps implement such a feature if (and only if) I don't 
> have any copyright assigment to find. In my GCC contributing
> experience fifteen years ago, that administrative step was really
> painful. I am too old to start such nightmares again.

The GNU project, of which GNU Make is a part, still does require
copyright assignment for any contribution of "significant" size, which
generally means patches that are more than 15 or so lines long.

Assignment has gotten simpler: in many jurisdictions (including some
non-U.S. countries) it can all be done online.  But if you work for a
company which has a claim to the work you did you would have to get a
disclaimer from them as well which can be onerous (depending on the
company of course).

Cheers!

-- 
Paul D. Smith Find some GNU make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: New conditional assignment facility

[Paul Smith]

On Mon, 2024-01-22 at 08:15 -0500, Paul Smith wrote:
> Let's step back and I'll try to think more clearly about this.

Sorry for the delay in replying.

I can see that I was thinking about this one way but there's another
way to look at it that I didn't think of.  We are talking only about
(a) append operators _other than_ +=, and (b) situations where the
variable already has a value when the append operator is parsed.

In all cases we would expand the right-hand side of the variable
according to the assignment operator: e.g., if it were +:= we would
immediately expand the RHS.

My proposal was to keep the type of variable (recursive vs. simple) the
same and then "fix up" the result of the RHS so it could be appended in
a correct way.  In this conception the operator applies ONLY to the RHS
value, and will set the type of the variable only if the variable
doesn't already exist, as a side-effect.

The other way to think about it is that the assignment operator
overrides the type of the variable as well: we would re-evaluate the
LHS value then append the RHS.  E.g., if it were +:= we would
immediately expand the RHS as well and change the type of simple.  In
this conception the operator resets the type of the variable as its
primary function, not just as a side-effect, and modifies not just the
RHS value but also (possibly) the LHS value as well.

An example to make this clearer:

Given:

foo = 1
  bar   = $(foo)
foo = 2
  bar +:= $(foo)
foo = 3
  bar  += $(foo)

$(info bar=$(bar))

In my original version, the result would be that "bar" is a recursive
variable with the value "$(foo) 2 $(foo)" and the output of the info
function would be "bar=3 2 3".

In the alternative version, the result would be that "bar" is a simple
variable with the value "2 2 3" and the output of the info function
would obviously be "bar=2 2 3".

I'm interested in peoples' opinions about which of these two
implementations they would feel to be more "intuitive" or "correct". 
Also please consider issues of "action at a distance" where a variable
is assigned in one makefile and appended to in some other makefile,
potentially far away.


This discussion has really helped me crystallize the differences and
should make the resulting documentation, if/when it's written, much
more clear so I definitely appreciate it!

-- 
Paul D. Smith Find some GNU make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

RE: New conditional assignm ent facility

[rsbecker]

On Saturday, January 27, 2024 3:33 PM, Paul Smith wrote:
>On Mon, 2024-01-22 at 08:15 -0500, Paul Smith wrote:
>> Let's step back and I'll try to think more clearly about this.
>
>Sorry for the delay in replying.
>
>I can see that I was thinking about this one way but there's another way to 
>look at it
>that I didn't think of.  We are talking only about
>(a) append operators _other than_ +=, and (b) situations where the variable 
>already
>has a value when the append operator is parsed.
>
>In all cases we would expand the right-hand side of the variable according to 
>the
>assignment operator: e.g., if it were +:= we would immediately expand the RHS.
>
>My proposal was to keep the type of variable (recursive vs. simple) the same 
>and
>then "fix up" the result of the RHS so it could be appended in a correct way.  
>In this
>conception the operator applies ONLY to the RHS value, and will set the type 
>of the
>variable only if the variable doesn't already exist, as a side-effect.
>
>The other way to think about it is that the assignment operator overrides the 
>type
>of the variable as well: we would re-evaluate the LHS value then append the 
>RHS.
>E.g., if it were +:= we would immediately expand the RHS as well and change the
>type of simple.  In this conception the operator resets the type of the 
>variable as its
>primary function, not just as a side-effect, and modifies not just the RHS 
>value but
>also (possibly) the LHS value as well.
>
>An example to make this clearer:
>
>Given:
>
>foo = 1
>  bar   = $(foo)
>foo = 2
>  bar +:= $(foo)
>foo = 3
>  bar  += $(foo)
>
>$(info bar=$(bar))
>
>In my original version, the result would be that "bar" is a recursive variable 
>with the
>value "$(foo) 2 $(foo)" and the output of the info function would be "bar=3 2 
>3".
>
>In the alternative version, the result would be that "bar" is a simple 
>variable with the
>value "2 2 3" and the output of the info function would obviously be "bar=2 2 
>3".
>
>I'm interested in peoples' opinions about which of these two implementations 
>they
>would feel to be more "intuitive" or "correct".
>Also please consider issues of "action at a distance" where a variable is 
>assigned in
>one makefile and appended to in some other makefile, potentially far away.
>
>
>This discussion has really helped me crystallize the differences and should 
>make the
>resulting documentation, if/when it's written, much more clear so I definitely
>appreciate it!

Intuitive reading of this would seem that "bar=2 2 3" is better, as +:= should 
force complete resolution of the string applied to bar, not partial resolution 
of foo keeping an instance of $(foo) for resolution later.

Just my $0.02.
Randall

Re: New conditional assignm ent facility

[Paul Smith]

On Sat, 2024-01-27 at 15:52 -0500, rsbec...@nexbridge.com wrote:
> > I'm interested in peoples' opinions about which of these two
> > implementations they would feel to be more "intuitive" or
> > "correct".  Also please consider issues of "action at a distance"
> > where a variable is assigned in one makefile and appended to in
> > some other makefile, potentially far away.
> 
> Intuitive reading of this would seem that "bar=2 2 3" is better, as
> +:= should force complete resolution of the string applied to bar,
> not partial resolution of foo keeping an instance of $(foo) for
> resolution later.

Hm, maybe I'm just weird.  Or maybe I chose a poor example.

What if the example was like this:

  foo_ARGS = -a
  bar_ARGS = -b
  ARGS = $($@_ARGS) -x

  all: foo bar
  foo bar: ; cmd $(ARGS) $@

  ARGS +:= $(shell gen-args)

where the "gen-args" program outputs "-z".

and now the value of ARGS would either be "$($@_ARGS) -x -z" using the
method I was suggesting, or it would be " -x -z" using the alternative
method where ARGS was converted into a simple variable.

So using the first method make would run:

  cmd -a -x -z foo
  cmd -b -x -z bar

and using the alternative method make would run:

  cmd  -x -z foo
  cmd  -x -z bar

Is it still more intuitive?  Maybe the answer is "well, just don't do
that" :).  Or maybe "+!=" could be used in this specific situation, but
you get the idea.

The problem is that when you write the assignment +:= it's not always
so simple to know what the side-effects might be because you don't know
what the current behavior of the variable is, and it might change in
the future.  Of course, that's always a problem with makefiles.

-- 
Paul D. Smith Find some GNU make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

[bug #65211] Fix load and loadapi tests.

[Paul D. Smith]

Follow-up Comment #2, bug#65211 (group make):

Thanks Dmitry!


___

Reply to this item at:

  

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

Re: make manual feedback

[Paul Smith]

On Mon, 2024-01-22 at 21:16 +, David Apps wrote:
> I have some feedback about the document at the following address:

Thanks for your feedback.

I applied all these changes, or some form of them, except:

> > Do not install executables here in this directory
> 
> Perhaps delete "here".
> 
> > Also do not install files that are modified in the normal course of
> their use
> 
> Perhaps change "install files" to "install in this directory any
> files".

These changes need to be made in the make-stds.texi file which is
distributed by the gnulib project.

You can reach them at bug-gnu...@gnu.org

Cheers!

-- 
Paul D. Smith Find some GNU make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

RE: New conditional assignm ent facility

[rsbecker]

On Saturday, January 27, 2024 4:14 PM, Paul Smith wrote:
>On Sat, 2024-01-27 at 15:52 -0500, rsbec...@nexbridge.com wrote:
>> > I'm interested in peoples' opinions about which of these two
>> > implementations they would feel to be more "intuitive" or "correct".
>> > Also please consider issues of "action at a distance"
>> > where a variable is assigned in one makefile and appended to in some
>> > other makefile, potentially far away.
>>
>> Intuitive reading of this would seem that "bar=2 2 3" is better, as
>> +:= should force complete resolution of the string applied to bar,
>> not partial resolution of foo keeping an instance of $(foo) for
>> resolution later.
>
>Hm, maybe I'm just weird.  Or maybe I chose a poor example.
>
>What if the example was like this:
>
>  foo_ARGS = -a
>  bar_ARGS = -b
>  ARGS = $($@_ARGS) -x
>
>  all: foo bar
>  foo bar: ; cmd $(ARGS) $@
>
>  ARGS +:= $(shell gen-args)
>
>where the "gen-args" program outputs "-z".
>
>and now the value of ARGS would either be "$($@_ARGS) -x -z" using the method I
>was suggesting, or it would be " -x -z" using the alternative method where ARGS
>was converted into a simple variable.
>
>So using the first method make would run:
>
>  cmd -a -x -z foo
>  cmd -b -x -z bar
>
>and using the alternative method make would run:
>
>  cmd  -x -z foo
>  cmd  -x -z bar
>
>Is it still more intuitive?  Maybe the answer is "well, just don't do that" 
>:).  Or maybe
>"+!=" could be used in this specific situation, but you get the idea.
>
>The problem is that when you write the assignment +:= it's not always so 
>simple to
>know what the side-effects might be because you don't know what the current
>behavior of the variable is, and it might change in the future.  Of course, 
>that's
>always a problem with makefiles.

My take on it is that +:= (because of the : ) means that you have to resolve 
everything at that point. So whatever ARGS might be when +:= is encountered, it 
is resolved completely. The result of ARGS prior to applying +:= could be 
anything, but +:= appends -z to whatever its current value is. The problem is 
that foo bar: ; cmd $(ARGS) is not resolved until the end of parse, but the 
value of ARGS just after recipe is resolved and applies to the command. If that 
is not correct, maybe do not do this.