bugmake - Bugs: bug #54630, "obsolete" language too...


bug #54630: "obsolete" language too strong

Submitted by:  David Boyce <boyski>
Submitted on:  Fri 07 Sep 2018 03:14:01 PM UTC  
Severity:  3 - Normal Item Group:  Documentation
Status:  Fixed Privacy:  Public
Assigned to:  Paul D. Smith <psmith> Open/Closed:  Closed
Component Version:  4.2.1 Operating System:  None
Fixed Release:  4.3 Triage Status:  None

Add a New Comment (Rich Markup)

You are not logged in

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


Sun 09 Sep 2018 07:55:04 PM UTC, comment #2: 

The docs for .SILENT were already updated to remove the "obsolete" reference, here: http://git.savannah.gnu.org/cgit/make.git/commit/?id=3daaa4dd3e6bb41841d5ec60ba47f7e4220162f5

I'll make changes in the other areas mentioned below.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Sat 08 Sep 2018 03:39:46 AM UTC, comment #1: 

Another example is the advice not to omit parens in references to single-character variables: "you could reference the variable x with ‘$x’. However, this practice is strongly discouraged, except in the case of the automatic variables..." I've found that in the bodies of user-defined functions, particularly those already laden with parentheses, '$1' is significantly more readable than '$(1)'. Suggested tweak: "the usual style is to include the parentheses except in the case of automatic variables..." Unless there's some reason other than style preference, in which case that reason should be spelled out.

Sam Kendall <sckendall>
Fri 07 Sep 2018 03:14:01 PM UTC, original submission:  

There are a few places in the manual where I feel the deprecation language is too heavy handed. For instance:

1. Of the automatic variables like $(@D) it says "These variants are semi-obsolete in GNU make since the functions dir and notdir can be used to get a similar effect". The latter part is true, of course, but the shorthand forms (a) are not going away, (b) are not deprecated, and (c) are more compact. It seems to me entirely a matter of preference and style whether to use the functions or the shorthand and no thumb should be placed on the scale. It's perfectly reasonable to point out both alternatives but not, IMHO, to deprecate one. Unless of course it's literally deprecated in which case the reason should be spelled out.

2. Similarly, and somewhat more importantly, it says ".SILENT is essentially obsolete since ‘@’ is more flexible". I disagree since I think there are cases where global silencing is preferable to having to enumerate each recipe line and add @ to it. I think the better answer is that there are cases where either is preferable and the two can and always will live comfortably together, along with -s/--silent.

I noticed this because I recently wrote a makefile suite with an unusual verbosity scheme: traditional make verbosity is turned off globally via .SILENT: and each target is assigned a "verbosity class" via a macro using $(eval ....). When make is run with V=n it results in a target-specific assignment of ".SHELLFLAGS := -x $(.SHELLFLAGS)" causing targets in verbosity class "n" to enable shell, not make, verbosity.

This system has its good and bad points and I'm not going to elaborate or push it here because it's orthogonal, other than to point out that it's a perfectly legitimate use of .SILENT. Having to go through the makefile and add @ to each line would damage the simplicity of the model; the whole idea is that after assigning a verbosity class to each target the makefile maintainer can stop worrying about verbosity.

PS A similar scheme might avoid the .SHELLFLAGS += -x business and simply use prerequisites of .SILENT to turn on and off traditional make verbosity per target. Another reasonable use case for .SILENT.

3. The phrasing for .IGNORE is nearly identical to .SILENT and may be subject to the same critique though I don't have a use case for .IGNORE.

These issues are not critical but they arise because I sometimes have to defend against charges of using obsolete features in new code. I think these features are not really obsolete; they may have been supplanted for some use cases by newer and more flexible features but that does not necessarily make them obsolete or deprecated and I wish the wording would be adjusted to clarify that.

David Boyce <boyski>


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

Attach Files:

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 sckendall (Posted a comment)
  • -email is unavailable- added by boyski (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
    2018-09-15 psmith StatusNone => Fixed
        Open/ClosedOpen => Closed
        Fixed ReleaseNone => 4.3
    2018-09-09 psmith Assigned toNone => psmith

    Back to the top

    Powered by Savane 3.7