[bug #57751] Improve POSIX support for SCCS

[Bruce Lilly]

Follow-up Comment #13, bug #57751 (project make):

> that functionality couldn't be used here else the $@ would expand to the
target, which in this case is .SCCS_GET so it's not what you want.

Good point.

> I don't believe that this (allowing $@ in prerequisites) is "traditional
make" behavior.

I've seen it used, e.g. where there are many executables, each built from a
single source file.  So, for example:


cat date echo ls pwd rm sleep sync test : $@.o


suffices to specify (with default rules) everything needed to build those
executables.  Otherwise, you'd have to have many separate dependency lines,
one each for every executable (or rely on default "suffix" rules with a null
suffix (and that wouldn't provide for any grouping such as using a specific
recipe with a special -l linker option attached to the dependency line, which
can be done in the above case)).  Obviously, that only works for variants of
make that support $@ (and/or its variants, like $*, $(@D), etc.) in the
prerequisites.  There are portable ways to deal with cases like the above, but
they're not as elegant.  There are cases where $(@D) and/or $(@F) in
prerequisites is/are very useful, and the workarounds are tedious.

The POSIX (X/Open) specification appears to support this; the "Target Rules"
section (2018 edition) applies where prerequisites are specified (as distinct
from "Inference Rules", which have only a single target and no prerequisites).
 And the "Internal Macros" section specifies the macros that can be used in
both target and inference rules, and clarifies "prerequisite".  It specifies
evaluation of $@ and $? for target rules, and $% for target rules when the
target is an archive library member.  $* is required to be evaluated for
inference rules, but evaluation is not prohibited for target rules.  $< is
specified for inference rules only.  There is nothing in the clarification of
"prerequisite" or elsewhere in the specification that excludes evaluation of
those internal macros in prerequisites in target rules.  For that matter,
there's only common sense (nothing explicit in the spec.) that precludes
evaluation in the target portion of a target rule (likewise, $? would make no
sense in a prerequisite).

The standard could be clearer on evaluation in prerequisites, as there is a
definite, well-documented (e.g. the previously-mentioned O'Reilly book by
Talbott and Oram) difference in historical (and, obviously, present)
implementations.  There's no mention in the standard's APPLICATION USAGE or
RATIONALE sections.

There's yet another variant with two dollar signs (which is mentioned in a
note in the POSIX X/Open spec.) that is specifically not included.

> Is it really the case that you define the COMMAND to run SCCS get operations
as PREREQUISITES to the special target?
>
> That's.... horrible and disgusting.

I'm guessing that you may have indeed found an error in the specification, but
I'm not certain of that.

Many "special" targets have horrible and disgusting syntax (which often causes
portability issues).  For example, NetBSD make (a.k.a. bmake) has a "special"
target for specifying the shell to use for recipes:


     .SHELL   Sets the shell that bmake will use to execute commands.  The
              sources are a set of field=value pairs.

              name        This is the minimal specification, used to select
                          one of the built-in shell specs; sh, ksh, and csh.

              path        Specifies the path to the shell.

[...]
              Example:

              .SHELL: name=ksh path=/bin/ksh hasErrCtl=true \
                      check="set -e" ignore="set +e" \
                      echo="set -v" quiet="set +v" filter="set +v" \
                      echoFlag=v errFlag=e newline="'\n'"


That looks like a target with a bunch of very peculiar prerequisites; it can
cause trouble for other make variants if it's the first (default) target, and
some other make variants (particularly dmake) complain about the syntax.

    _______________________________________________________

Reply to this item at:

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

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