[bug #54630] "obsolete" language too strong

[David Boyce]

URL:
  <https://savannah.gnu.org/bugs/?54630>

                 Summary: "obsolete" language too strong
                 Project: make
            Submitted by: boyski
            Submitted on: Fri 07 Sep 2018 03:14:01 PM UTC
                Severity: 3 - Normal
              Item Group: Documentation
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 4.2.1
        Operating System: None
           Fixed Release: None
           Triage Status: None

    _______________________________________________________

Details:

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 address@hidden 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.




    _______________________________________________________

Reply to this item at:

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

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