[bug #57751] Improve POSIX support for SCCS

[Paul D. Smith]

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

That is not dispositive because it tells you where the macro is _evaluated_
but doesn't tell you where an internal macro is _assigned_.

Where it is assigned is the key question, not where it is evaluated.

For a rule like this:

foo.o : $@.c ;

clearly the $@ is evaluated when the target line is read in, as POSIX says,
but POSIX also says that internal macros "can be used in target and inference
rules", so there is absolutely nothing in the standard saying that make should
not work like this:

  * Parse/evaluate the target
  * Assign $@ to the target name
  * Parse/evaluate the prerequisites

That is why I asked for the text to be clarified saying that internal macros
are not required to be assigned except when evaluating commands.

___

Reply to this item at:

  

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

[bug #57751] Improve POSIX support for SCCS

[Jörg Schilling]

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

Just in case that helps, the syntax of the make language is not written down
cleanly as a compact syntax description in the POSIX standard. You need to
read a lot of the general text. My explanations about the expansions of macros
at parse time are in the macro section of the standard.

See this quote from the standard:

Macros can appear anywhere in the makefile. Macro expansions using the forms
$(string1) or ${string1} shall be replaced by string2, as follows:

-   Macros in target lines shall be evaluated when the target line is read.

.   Macros in makefile command lines shall be evaluated when the command is
executed.

.   Macros in the string before the  in a macro definition shall
be evaluated when the macro assignment is made.


___

Reply to this item at:

  

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

[bug #57751] Improve POSIX support for SCCS

[Paul D. Smith]

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

RE: what POSIX says about internal macros and where they are valid: I agree
with Jörg that no POSIX-based make supports $@ in prerequisite lists. 
However I agree with Bruce that the standard is at best ambiguous about this
and I've filed:

https://www.austingroupbugs.net/view.php?id=1420

to request clarification.

RE: handling $$@ : it's not true that GNU make doesn't support this: GNU make
_DOES_ support this syntax but you have to enable it; see:

https://www.gnu.org/software/make/manual/html_node/Secondary-Expansion.html

There has been thought about making it enabled by default but it hasn't
happened yet.

___

Reply to this item at:

  

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

Re: [bug #57751] Improve POSIX support for SCCS

[Henrik Carlqvist]

On Sat,  7 Nov 2020 20:56:37 -0500 (EST)
Bruce Lilly  wrote:

> 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,

I agree that allowing $@ in prerequisites would allow easy to read and easy to
write Makefiles, but the lack of that functionality does not mean that the
same build method for multiple targets needs to get split up to different
dependency lines. With a static pattern rule you can do the same on with a
single line:

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

regards Henrik

[bug #57751] Improve POSIX support for SCCS

[Jörg Schilling]

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

Please read my previous answer...

Any dependency line in e.g. the form:

$(TGT): $(DEPS)

is completely expanded at the time the parser reads the makefile, so in this
example, $(TGT) and $(DEPS) already need to have a value at the time, the
dependency line is read/parsed. So POSIX requires to expand $@ to an empty
string and bmake is clearly in conflict with POSIX.

Special macros only have values at the time, when the update process is
updating a target.

What you like to get is not make syntax and if you believe that the POSIX
standard supports your wish, then the POSIX text should be fixed to become
less ambiguous.

BTW: There is a SunPro Make enhancement (since 1986) that would need to use:

foobar : $$@.blurfl

with the behavior you like but this is not covered by POSIX nor by other make
implementations. well except for bmake, that also seems to support it.

Unlike the syntax you reported for bmake, the $$@ syntax is a clean
enhancement to UNIX / POSIX make that is not in conflict with the standard.

See the man page:

 $@The name of the  current  target.  This  is  the  only
   dynamic  macro whose value is strictly determined when
   used in a dependency list. (In which case it takes the
   form $$@.)


___

Reply to this item at:

  

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

[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.

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

  pathSpecifies 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:

  

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

[bug #57751] Improve POSIX support for SCCS

[Jörg Schilling]

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

Re: comment #8: you are mistaken.

gmake has some deviations from POSIX and a classical UNIX make but these
deviations are *much* less important than the deviations found in bmake.

The BSD make program is not related to any UNIX make program, it was derived
from a program called pmake.

$ cat Makefile
foobar : $@.blurfl
$ make 
make: Fatal error: Don't know how to make target `.blurfl'
$ dmake
dmake: defaulting to parallel mode.
make: Fatal error: Don't know how to make target `.blurfl'
$ smake
smake: Can't find any source for '.blurfl'.
smake: Couldn't make 'foobar'.
$ gmake
gmake: *** No rule to make target `.blurfl', needed by `foobar'.  Stop.
$ bmake
bmake: don't know how to make foobar.blurfl. Stop

BTW: Make macros to the right of a colon are expanded by the parser already
and at that time, $@ is undefined.

I hope this explains the correct behavior of various make implementations.

___

Reply to this item at:

  

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

[bug #57751] Improve POSIX support for SCCS

[Paul D. Smith]

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

I filed https://austingroupbugs.net/view.php?id=1419 to address this typo.

___

Reply to this item at:

  

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

[bug #57751] Improve POSIX support for SCCS

[Paul D. Smith]

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

I forgot my main point, which was: whether or not $@ is "traditionally"
allowed to appear in the prerequisites list makes no difference in this
situation.  Even if it were, 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.

It's clear that if the command is provided as prerequisites to the target then
the entire thing must be handled as a special case.

However, looking at the spec this is all moot because, indeed, the rule quoted
below is a typo in the spec.

The text of the spec makes very clear that it's the _commands_ of this special
target that specify the rule:

> The application shall ensure that this special target is specified without
prerequisites. If this special target is included in a makefile, the commands
specified with this target shall replace the default commands associated with
this special target (see Default Rules). The commands specified with this
target are used to get all SCCS files that are not found in the current
directory.

___

Reply to this item at:

  

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

[bug #57751] Improve POSIX support for SCCS

[Paul D. Smith]

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

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

However, I admit to being surprised when I went to look at the POSIX spec for
make that it is very wishy-washy and unclear as to exactly where the internal
macros are available.  It just says they "can be used in target and inference
rules".  I would have expected it to say that specifically that they can be
used in commands.

So, maybe I'm wrong.

In any event, I assumed that this is a typo.  I thought that the rule was
intended to be:


.SCCS_GET: ; sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@


Note the added semicolon.

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.

___

Reply to this item at:

  

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

[bug #57751] Improve POSIX support for SCCS

[Bruce Lilly]

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:

  

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

[bug #57751] Improve POSIX support for SCCS

[Jörg Schilling]

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

Just a note to the XSI "enhancements" to POSIX

Implementing all XSI enhancements is required in order to get the permission
to call a platform "UNIX" compatible and thus to use the UNIX trademark.

A platform that implements support for XSI is a full blown POSIX system and if
XSI is not or not completely implemented, this is typical choice for tiny
platforms, e.g. embedded systems.

BTW: SunPro Make is POSIX+XSI certified and gmake is not faster than SunPro
Make. Gmake even needs a tiny bit more CPU time than SunPro Make. So I am not
sure whether implementing SCCS support really creates a performance problem.

___

Reply to this item at:

  

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

[bug #57751] Improve POSIX support for SCCS

[Bruce Lilly]

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

[comment #3 comment #3:]
> I can't remember the last time I saw a system where SCCS or RCS were even
installed.

SCCS is alive and well; it was open-sourced by Sun Microsystems as part of
Open Solaris and is still being updated (slowly, because it's stable), has
mailing lists, etc.  I use SCCS extensively.  But this isn't the time or place
for advocacy; if you want to know why, here or off-list, ask me.

Some of the finer points about SCCS-related rules:
1. the tilde hack exists because make originally worked on suffixes whereas
SCCS uses prefixes ("s." and related ones).  Obviously gmake has a more
general pattern-based rules system; one way to achieve compatibility would be
an internal translation of a tilde suffix rule to an equivalent pattern.  The
most general way would be to translate a '~' suffix (in suffix rules) to a
pattern "s.%" or something like that.  Note that some programs sometimes
generate files with a literal tilde at the end of the filename (typically for
backups), which is distinct from the make suffix rule tilde hack, which
doesn't involve any tilde in the actual file name.  Anyway, as shown below, it
appears to work in gmake, at least in version 4.2.1.
2. When an SCCS-cognizant version of make is used, it can retrieve the
makefile itself (from s.makefile or s.Makefile or SCCS/s.makefile, etc.) with
no special action on the part of the user; 'make' suffices.  Gmake already
does this (including s.GNUmakefile, etc.).
3. Sometimes SCCS source files exist in the same directory as the target file,
sometimes in an "SCCS" subdirectory.  Gmake appears to handle both cases
adequately.
4. SCCS-cognizant versions of make typically have several built-in rules
primarily aimed at C source programming (e.g.
https://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/make/pwbrules.c
[*]).  Users interested in version control and automation of other tasks
(documentation, audio or video production, etc.) or in other programming
languages may have additional defined suffixes and suffix rules.  For
compatibility, at least the basic yacc/lex/.c/.h/.sh/.s rules should probably
be supported.
5. Much of this already exists in gmake:

$ gmake --version ; gmake hw.o
GNU Make 4.2.1
Built for x86_64-suse-linux-gnu
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
get   SCCS/s.GNUmakefile
Clock may be set wrong! (co11)
1.1
2 lines
No id keywords (cm7)
get   SCCS/s.makefile
Clock may be set wrong! (co11)
1.1
2 lines
No id keywords (cm7)
get   s.hw.c
1.1
6 lines
No id keywords (cm7)
cc-c -o hw.o hw.c
rm hw.c


Neither of the makefiles have any specific rules for hw.[co] or explicit
suffix rules for SCCS; everything that gmake did was based on internal rules.

6. Gmake appears to support the tilde hack reasonably well for additional
user-defined suffixes:

$ ls -l *.pic*
-rwxrwxrwx 1 root root 281 Sep 17 16:11 s.foo.pic
$ gmake foo.pic
get   SCCS/s.GNUmakefile
1.2
9 lines
No id keywords (cm7)
get   SCCS/s.makefile
Clock may be set wrong! (co11)
1.1
2 lines
No id keywords (cm7)
get   s.foo.pic
1.1
6 lines
No id keywords (cm7)
$ ls -l *.pic* 
-rwxrwxrwx 1 root root  99 Sep 17 16:11 foo.pic
-rwxrwxrwx 1 root root 281 Sep 17 16:11 s.foo.pic
$ cat SCCS/GNUmakefile   
# add .pic and .pic~ suffixes
.SUFFIXES : .pic .pic~

# SCCS get
GET = get

# rule to get
.pic~.pic :
if test -n "$(GET)" ; then $(GET) s.$@ ; fi


Note: nothing there is gmake-specific; there are no files with a literal
tilde, etc.  Gmake gets the desired file using get. Note also that the suffix
rule is generic enough that if you have defined suffixes .foo and .foo~, it
will work for them also by adding the concatenated suffix target .foo~.foo to
the suffix rule target list.  So a more complete suffix rule might include
targets .cpp~.cpp .tbl~.tbl .grap~.grap .1~.1 etc.

Bogdan wrote:
> Also, suffixes such as ".foo~" (meaning ".foo" files prefixed by a "s.") do
not seem to be supported.

Do you have a specific example (note that it appears to work fine for .pic~)? 
What specific suffix seems to be the problem, what suffixes and suffix rules
are defined, are the relevant macros defined, which version of gmake, etc.?

So, I'm not seeing any general SCCS-related issues here, including some of the
subtleties.

> .SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@

I believe that it's possible to get desired functionality using suffixes and
suffix rules w/o such 'special' targets; see the examples above.  It might
well be the case that gmake doesn't work the way the POSIX committee would
like to see it work, but that's a different matter from solving real-world
problems.  If the goal is strict conformity to the standards documents, that's
one thing; if there's a specific real problem that 

[bug #57751] Improve POSIX support for SCCS

[Bogdan Barbu]

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

Ugh, paperwork? Is this something that has to be done everytime people send
patches? I mean it's literally just a couple of small additions:

1. If foo is a dependecy and SCCS/s.foo exists, then make issues the commands
specified in .SCCS_GET, whose default is this:

.SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@

but makefiles can provide their own .SCCS_GET instead.

2. A syntax for suffixes like .c~ which really means s.%.c.

If you don't have time to do it can't I just release the patches into public
domain and have you incorporate them or something so I don't have to sign
papers and send them to other countries? Sounds like a hassle, unless there's
some simple procedure in place that I can waste a few minutes on online.

___

Reply to this item at:

  

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

[bug #57751] Improve POSIX support for SCCS

[Bogdan Barbu]

URL:
  

 Summary: Improve POSIX support for SCCS
 Project: make
Submitted by: love4boobies
Submitted on: Thu 06 Feb 2020 09:10:00 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

According to POSIX, makefiles should be able to replace the special rule
.SCCS_GET in order to specify how to get SCCS files that do not exist in the
current directory. The default is:

.SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@

Also, suffixes such as ".foo~" (meaning ".foo" files prefixed by a "s.") do
not seem to be supported. I am aware that these can be done in other ways with
GNU Make, but for portability's sake, they should be there.




___

Reply to this item at:

  

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