bugmake - Bugs: bug #57751, Improve POSIX support for SCCS

 
 

bug #57751: Improve POSIX support for SCCS

Submitted by:  Bogdan Barbu <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
Component Version:  None Operating System:  None
Fixed Release:  None Triage Status:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 17 Sep 2020 09:50:26 PM UTC, comment #6: 

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 <http://gnu.org/licenses/gpl.html>
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 you're trying to solve in a portable way, there may be a better way to address it -- certainly the installed base of pre-committee software isn't going to magically start working the way some document describes if it didn't work that way before; and both make and SCCS have been around for decades.  On the other hand, many existing make implementations, including gmake, work well with SCCS using portable, well-documented mechanisms such as .SUFFIXES and suffix rules.

* There should be enough information there (in concise form) to implement any missing support for specific recipes.  I don't know who "my" in the comments in the source file refer to; it's not me!

Bruce Lilly <blilly>
Wed 01 Apr 2020 01:28:37 PM UTC, comment #5: 

The FSF guidelines consider any changes more than 15 to 20 lines to be "legally significant" and require paperwork.  My suspicion is that the changes you're talking about would be more than that, but you can try it and see.  Maybe I'm overestimating.

You can certain disclaim copyright rather than assigning copyright to the FSF; some people don't want to assign copyright for various reasons.  However, "public domain" as a legal concept doesn't exist in many countries so it's not so easy, legally, as just writing a message at the top of the changes.  You still need to fill out a form :(

The FSF has different forms for assigning copyright and disclaiming copyright.  Either one is fine.  They also have forms for assigning all future changes so you don't have to continue to file paperwork if you plan to continue to contribute.

For many countries this can be done via email and there's no actual paper involved.  However if by "online" you mean a web form or something then no, we don't have that.

Paul D. Smith <psmith>
Project Administrator
Thu 20 Feb 2020 06:31:00 PM UTC, comment #4: 

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.

Bogdan Barbu <love4boobies>
Mon 17 Feb 2020 04:15:00 PM UTC, comment #3: 

Sure.  Be aware that as a GNU project, changes of that order will likely require copyright assignment paperwork before they can be included.

> Seems reasonable. A different approach would be to add a command-line option to disable the built-in support for these tools so people can just accelerate the performance of make in a transparent way to any makefile relying on the current behavior.


I don't think that a command line argument is the right way to go.  It should be up to the makefile, and defined there, whether these rules are omitted, not up to the user of the makefile.  There is precedent of course (the -r option for example) but I still don't think it's the right design.

The thing is that makefiles can already get rid of these rules if they want to; we could make it simpler but it's just a matter of magnitude.  What I would prefer is to have these rules disabled by default, without users having to do anything, since virtually no one wants them.  I can't remember the last time I saw a system where SCCS or RCS were even installed.  Even the BSD systems are using CVS now IIRC.  Then the people who do need this support can add it back: they likely already know how to do it.

Of course this would be a backward-compatibility break and that's always concerning.  If I discover there's any non-trivial audience relying on these built-in rules I probably wouldn't do it.

Paul D. Smith <psmith>
Project Administrator
Mon 17 Feb 2020 10:08:02 AM UTC, comment #2: 

> I don't have any objection to including these features in GNU make if someone contributes them, but I have little enthusiasm for creating these myself since I doubt that SCCS is much more than an anachronism these days.  Certainly no one has ever complained about this before in the history of GNU make (that I'm aware of).  I'd prefer to spend my (very limited) time on more useful features and fixes.


I'd be willing to write a patch to add support for these features but I am not very familiar with GNU Make's code base yet so I'll probably have a few questions along the way to get my way around it faster and also to make sure I don't accidentally break anything. What would be the appropriate place to ask such questions?

> In fact, I've been toying with the idea of omitting the built-in rules for RCS and SCCS completely, unless the .POSIX: special target is given (I realize RCS is not part of the POSIX standard), because adding extra match-anything rules like these seriously impacts the performance of make, and not many makefiles think to delete these rules which virtually no one ever uses/needs anymore.  It's just a big waste of cycles.


Seems reasonable. A different approach would be to add a command-line option to disable the built-in support for these tools so people can just accelerate the performance of make in a transparent way to any makefile relying on the current behavior.

Bogdan Barbu <love4boobies>
Sun 16 Feb 2020 06:25:06 PM UTC, comment #1: 

Well, SCCS support in make is actually part of the XSI extension to POSIX, not base POSIX.

I don't have any objection to including these features in GNU make if someone contributes them, but I have little enthusiasm for creating these myself since I doubt that SCCS is much more than an anachronism these days.  Certainly no one has ever complained about this before in the history of GNU make (that I'm aware of).  I'd prefer to spend my (very limited) time on more useful features and fixes.

In fact, I've been toying with the idea of omitting the built-in rules for RCS and SCCS completely, unless the .POSIX: special target is given (I realize RCS is not part of the POSIX standard), because adding extra match-anything rules like these seriously impacts the performance of make, and not many makefiles think to delete these rules which virtually no one ever uses/needs anymore.  It's just a big waste of cycles.

Paul D. Smith <psmith>
Project Administrator
Thu 06 Feb 2020 09:10:00 AM UTC, original submission:  

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.

Bogdan Barbu <love4boobies>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by blilly (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by love4boobies (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.5