bugmake - Bugs: bug #59399, Add a warning about using $* and...

 
 

bug #59399: Add a warning about using $* and $< in explicit rules

Submitted by:  Jörg Schilling <schily>
Submitted on:  Mon 02 Nov 2020 01:36:37 PM UTC  
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  Wont Fix Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  None Operating System:  None
Fixed Release:  None Triage Status:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 01 Dec 2020 02:57:52 PM UTC, comment #7: 

The output about "entering directory" is definitely important and it's certainly not confusing.

The output is used by (at least) Emacs's compile mode to allow it to track and correctly manage output, so it can understand the current working directory and use it to jump to source code correctly when processing error messages.

If you have output like this:

cc -o foo.o -c foo.c
cc -o bar.o -c bar.c
cc -o baz.o -c baz.c

versus this:

cc -o foo.o -c foo.c
... Entering directory subdir
cc -o bar.o -c bar.c
... Leaving directory subdir
cc -o baz.o -c baz.c

then in the first case we can't locate the file bar.c, but in the second case we can.  If we show only "entering" but not "leaving" messages then we think baz.c is in the subdir as well when it is not.

Locating makefiles is not the point of these messages so printing a working directory when showing make errors is not sufficient.  The real goal is to provide context for error messages that are printed by the commands make invokes.

If you don't like these messages and they're not needed in your environment (perhaps you always use fully-qualified source paths for your compilation) they're trivial to get rid of; just set GNUMAKEFLAGS=--no-print-directory in your environment.

If the only thing you care about is portability to smake and SunPro make then clearly the best way to test that is to run them.  Adding piecemeal warnings to GNU make will never solve this problem.  A makefile linter would obviously be intended to be much more generic and point out issues in smake/SunPro makefiles which would not work as expected in GNU make, or things that rely on features that aren't actually guaranteed by POSIX, etc.

Paul D. Smith <psmith>
Project Administrator
Tue 01 Dec 2020 01:23:10 PM UTC, comment #6: 

I would love to see gmake to avoid unneeded and confusing output.

I however see tons of messages like 'entering directory..' and
similar. If you like to see these kind of messages, I would
expect that people need to use a related option to enable
them. For the typical usage, it is sufficient that a typical
make implementation prints the current working together with
error messages.

BTW: If you like a separate makefile linter, you could already
just call smake or SunPro Make to check whether a makefile
contains non-portable constructs. But it seems that typical gmake
users are not using other free make implementations to verify
their makefiles.

Jörg Schilling <schily>
Mon 30 Nov 2020 06:51:44 PM UTC, comment #5: 

I don't want to add warnings for usage which is valid and well-defined by the GNU make manual, to the default output of GNU make.  People expect their make program to do its work without a lot of fuss, and they choose GNU make because they want to use it's enhanced capabilities, not be warned about using them.

Thinking about this more, I don't think I'd even accept a patch which introduced an option that users could enable to mention when non-portable features are used.  The definition of what is a "non-portable makefile" is pretty loose and changes over time, and will never be comprehensive.  Creating such a set of checks would be very time-consuming and would complicate the code, and, IME, is not something most people care much about.

Instead, I suggest that this time would be better spent creating a separate "makefile linter" tool that could be used by people who were interested in writing makefiles that adhered to a specific set of portability constraints.  Since this a tool wouldn't need to actually build things and would only be run periodically as a check, it would not need to be very efficient; in fact it would probably be simplest to write the tool in an interpreted language which is good at text processing such as Perl or Python.

If such a tool were created I'd be happy to review it to suggest or even contribute checks to point out common GNU make idioms people might be using that aren't portable.

Paul D. Smith <psmith>
Project Administrator
Sun 29 Nov 2020 11:30:07 PM UTC, comment #4: 

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.

Paul D. Smith <psmith>
Project Administrator
Sun 29 Nov 2020 11:01:53 PM UTC, comment #3: 

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.

Jörg Schilling <schily>
Fri 27 Nov 2020 04:49:59 PM UTC, comment #2: 

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.

Jörg Schilling <schily>
Fri 27 Nov 2020 03:21:28 PM UTC, 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?

Paul D. Smith <psmith>
Project Administrator
Mon 02 Nov 2020 01:36:37 PM UTC, original submission:  

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?

Jörg Schilling <schily>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by schily (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-30 psmith Open/ClosedOpen => Closed
        SummaryExpanding implicit macros in gmake (enhancement request) => Add a warning about using $* and $< in explicit rules
    2020-11-30 psmith StatusNone => Wont Fix
    2020-11-27 psmith Item GroupNone => Enhancement

    Back to the top


    Powered by Savane 3.7