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/