I changed the default installation to contain
$(INSTALLROOT)/lib/make/SCCS.mk
and the default get action for s.a.c is now
get s.a.c
the makerules { pax tar cpio } actions main purpose is to archive
the files required for building from scratch; for that purpose
the s.* files are appropriate
actions for packaging a.c instead of s.a.c would need some
thought and parameterization (s.*.* too or just *.*) and would be
better off having sccs-specific actions defined in SCCS.mk
I don't use { sccs cvs or equivalents } and my default paradigm
turns those on their head -- the source is the master and release
packaging inserts copyright notices, date stamps, and records the
diffs so they can be restored -- this plays right into the hands of
the git based www.research.att.com/sw/gitweb/ which is almost ready
so
I'll rely on you and other sccs users to provide input on sccs
specific pax etc
thanks
On Mon, 16 Jan 2012 19:49:55 -0500 Bruce Lilly wrote:
> On Mon, 16 Jan 2012 17:42:59 -0500
> Glenn Fowler <[email protected]> wrote:
> > [...] if it works for you then I'll make sure its
> > installed by default ---
> It partly works;
> the action to get a g-file is something like
> get s.a.c > a.c
> which doesn't work (get's standard output w/o the -p flag is to write
> the SID and number of lines; the above sometimes makes a correct g-file
> but returns a non-zero status which causes nmake to stop and to remove
> the g-file; frequently it (or maybe the shell) generates a fault due to
> the conflict between get's standard output and shell redirection vs.
> the g-file).
> Instead, simply
> get s.a.c
> should suffice as the default get action is to write the g-file.
> Otherwise
> get -p s.a.c > a.c
> would work with zero return status (and with SID and line count to
> stderr). My preference would be the simpler command (no -p flag, no
> redirection), and that is what gmake does by default. I'm guessing
> that the "return $(GET) ..." line is what needs to be changed, but the
> shallowness of my nmake understanding coupled with the terseness of
> nmake's programming language means I won't yet attempt a patch.
> Other than the above issue, nmake with your SCCS.mk file appears to do
> the right things if there is an outstanding edit (g-file already
> exists) and neither nmake clean nor nmake clobber do anything nasty.
> I'm undecided about nmake cpio; it would include the s-file if there's
> no g-file and both s-file and g-file if the latter exists, but not a
> p-file if there's an outstanding edit. FWIW, I'd normally package just
> g-files, using get to generate them if necessary (rarely if ever
> s-files). s-file plus under-edit g-file but w/o p-file sounds like
> trouble (again, g-file alone makes the most sense to me). I suspect
> (but haven't tested) that nmake tar, etc. behave similarly.
> It appears that (aside from the first issue above) the right things
> will happen for some more complex situations provided the dependencies
> specify the right files (e.g. if there's SCCS yacc source, the .y file
> needs to be specified on the target line).
> nmake documentation about dependencies might benefit from a note to the
> effect that SCCS files are an exception to the principle of specifying
> source files rather than intermediate files; nmake will try to compile
> the s-file if it's listed as a program dependency rather than the
> (intermediate) g-file.
> That's the extent of my testing.
> Thanks.
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
