Follow-up Comment #8, bug #57751 (project make):
A further note on:
> .SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@
in the original report. That's likely to be a problem for gmake as it stands,
separately from any SCCS-specific issues.
Gmake has a long-standing difference from other make variants in handling of
$@ and variants of it (e.g. $(@D)) as prerequisites (as distinct from use in
recipes). Here's a greatly simplified example:
$ cat makefile.dollar-at
foobar : $@.blurfl
$ uname -sr
OpenBSD 6.8
$ type -a make bmake gmake smake dmake
make is a tracked alias for /usr/bin/make
ksh93: whence: bmake: not found
gmake is a tracked alias for /usr/local/bin/gmake
ksh93: whence: smake: not found
ksh93: whence: dmake: not found
$ make -f makefile.dollar-at
make: don't know how to make foobar.blurfl (prerequisite of: foobar)
Stop in /data/projects/computing/make/tests
$ gmake -f makefile.dollar-at
gmake: *** No rule to make target '.blurfl', needed by 'foobar'. Stop.
$
So:
1. Like the quoted line, $@ appears in what syntactically looks like a
prerequisite on a single-colon dependency line
2. Two make variants tested here: OpenBSD native make and gmake
3. Note that the OpenBSD native make expands $@ in the prerequisite, which is
traditional make behavior
4. Note that gmake neither expands nor copies $@; it is effectively treated as
if it were whitespace! That difference between gmake and other make variants
is fairly well known and documented in a few places (e.g. the old O'Reilly
make books).
So handling that specific case verbatim is likely to first require handling $@
(and perhaps variants) on dependency lines *in general* in gmake.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?57751>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
