Re: [bug #59399] Expanding implicit macros in gmake (enhancement request)

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Sun, Nov 29, 2020 at 6:02 PM Jörg Schilling  wrote:
> I just verified that expanding $< and $* for explicit rules at all
> was an invention from SunPro Make. These macros have not been
> expanded by the classical UNIX make.


The seminal make manual of 1978 contains the following

"Before issuing any command, certain macros are set. $@ is set to the
name of the file to be ‘‘made’’. $? is
set to the string of names that were found to be younger than the
target. If the command was generated by
an implicit rule (see below), $< is the name of the related file that
caused the action, and $∗ is the prefix
shared by the current and the dependent file names."

See here
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.9198=rep1=pdf

regards, Dmitry

[bug #59399] Expanding implicit macros in gmake (enhancement request)

[Paul D. Smith]

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

As always I'm ignoring as irrelevant who implemented what first.

Using $< is very trivial.  It always expands to the first prerequisite in the
rule that contains the recipe.  That's true for double-colon rules as well of
course.  For example:


all: foo bar

foo:
foo: blah

foo: biz; : $<

bar:: boz yadda; : $<
bar:: baz yadda; : $<

biz boz baz blah yadda: ;@:


will print:


: biz
: boz
: baz


Using $* is more complicated but the GNU make manual describes it pretty well
I think:

https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html


 In an explicit rule, there is no stem; so '$*' cannot be determined
 in that way.  Instead, if the target name ends with a recognized
 suffix (*note Old-Fashioned Suffix Rules: Suffix Rules.), '$*' is
 set to the target name minus the suffix.  For example, if the
 target name is 'foo.c', then '$*' is set to 'foo', since '.c' is a
 suffix.  GNU 'make' does this bizarre thing only for compatibility
 with other implementations of 'make'.  You should generally avoid
 using '$*' except in implicit rules or static pattern rules.

 If the target name in an explicit rule does not end with a
 recognized suffix, '$*' is set to the empty string for that rule.


This text has not been changed since Roland's 1992 version of the manual.

___

Reply to this item at:

  

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

[bug #59399] Expanding implicit macros in gmake (enhancement request)

[Jörg Schilling]

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

Let me add a hint...

I just verified that expanding $< and $* for explicit rules at all
was an invention from SunPro Make. These macros have not been 
expanded by the classical UNIX make.

___

Reply to this item at:

  

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

[bug #59399] Expanding implicit macros in gmake (enhancement request)

[Jörg Schilling]

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

Well, it may be a bit confusing because I am maintaining two make
implementations. 

1)  The program smake, I wrote in the early 1980s and that is still
maintained.

2)  The SunPro Make program that Sun made OSS on my request in December 2006.

SunPro Make currently does not print warnings related to
these implicit macros, smake however does.

Smake prints these warnings because the internal structure of
smake makes it impossible to expand the implicit macro $< in
explicit rules.

Smake prints this warning:

smake: WARNING: requesting implicit dynmac '$<' for explicit target 'all'
smake: WARNING: expanding implicit dynmac  '$<' to ''
smake: WARNING: Current working directory:  '/home/joerg/cmd/smake', Makefile
'Mw'
smake: WARNING: requesting implicit dynmac '$*' for explicit target 'all'
smake: WARNING: expanding implicit dynmac  '$*' to 'all'
smake: WARNING: Current working directory:  '/home/joerg/cmd/smake', Makefile
'Mw'


The warning is printed by smake since more than 15 years. For
this reason, I do not remember the exact difference with
expanding these macros between gmake and SunPro Make. I
remotely remember that the differences appear with : vs. ::
type explicit targets.

Could you explain how these implicit macros are expanded in gmake?

For SunPro Make, I am currently thinking about whether I
should add similar warnings as in smake in case that the
Makefile is of unknown origin. SunPro Make currently
evaluates the environment SUN_MAKE_COMPAT_MODE and allows
to switch it's behavior based on that environment.

In theory, SunPro Make could be enhanced in a way that it
prints the related warning depending on thether this
make macro was not seen before.

___

Reply to this item at:

  

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

[bug #59399] Expanding implicit macros in gmake (enhancement request)

[Paul D. Smith]

Update of bug #59399 (project make):

  Item Group:None => Enhancement

___

Follow-up Comment #1:

Can you show what warning SunPro Make is printing when it sees these macros
being used in explicit rules, so I can understand better the kind of thing
you're looking for?

___

Reply to this item at:

  

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

[bug #59399] Expanding implicit macros in gmake (enhancement request)

[Jörg Schilling]

URL:
  

 Summary: Expanding implicit macros in gmake (enhancement
request)
 Project: make
Submitted by: schily
Submitted on: Mon 02 Nov 2020 01:36:37 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

POSIX mentions that the special make macros '$*' and '$<' only need to be
defined with implicit rules.

smake for this reason and because it's internal structure does not allow it,
does not expand $* or $< and prints a warning if these macros are encountered
in explicit rules.

SunPro Make expands these implicit macros, using an internal algorithm.

gmake also expands these implicit macros but uses a completely different
algorithm to get the values that by chance may give the same result as you get
from SunPro Make, but this may differ.

How about adding a warning to gmake if these macros are encountered with
explicit rules in order to warn users that they are writing or using a
non-portable makefile?





___

Reply to this item at:

  

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