bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul D. Smith
Subject: [bug #59399] Add a warning about using $* and $< in explicit rules
Date: Tue, 1 Dec 2020 09:57:52 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36

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

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.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59399>

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]