[bug #57751] Improve POSIX support for SCCS

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[bug #57751] Improve POSIX support for SCCS

David Boyce-5
URL:
  <https://savannah.gnu.org/bugs/?57751>

                 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:

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

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


Reply | Threaded
Open this post in threaded view
|

[bug #57751] Improve POSIX support for SCCS

David Boyce-5
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:

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

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


Reply | Threaded
Open this post in threaded view
|

[bug #57751] Improve POSIX support for SCCS

David Boyce-5
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 <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!

    _______________________________________________________

Reply to this item at:

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

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