I just finished sendmail mail to cgd (cc source-changes, not the best
list) about the .c.a rule in sys.mk that he disabled for the Alpha
port.

I believe everything I said in that mail is correct (so I still
question his decision), but there is more to the story.  If you read
6.2.7.6, it says:

	6.2.7.6 Libraries

	If a target or a prerequisite contains parentheses, it shall
	be treated as a member of an archive library.  For the
	lib(member.o) expression, lib refers to the name of the
	archive library and member.o to the member name.  The member
	shall be an object file with the .o suffix.  The modification
	time of the expression is the modification time for the member
	as kept in the archive library.  See 6.1.  The .a suffix
	refers to an archive library.  The .s2.a rule is usd to update
	a member in the library from a file with a suffix .s2.

In other words, .c.a isn't intended to generate a .a file from a .c
file at all, but rather to be used in something like:

	foo: foo(one.o) foo(two.o) foo(three.o)
		@echo foo is up to date.

gmake does implement these semantics, and does honor a .c.a rule if
you define your own.  If you do specify your own .c.a rule, gmake will
generate a .a file from a .c file; if you don't specify your own .c.a
rule, gmake will not generate a .a file from a .c file.  This seems to
suggest a deliberate decision not to apply implicit rules of the form
.foo.a, but after a careful reading, I can't find anything in the
standard to suggest that this is correct.

Our make doesn't appear to support library members at all, and fails
miserably on the example in the rationale.  (Incidentally, so does
OSF/1 and probably most other systems.)

Yech.