Re: sun-lamp CVS commits

[Greg Hudson <ghudson%mit.edu@localhost>]

> Modified Files:
>       sys.mk 
> Log Message:
> don't include the .c.a rule on the alpha.  see p.r. 1488 for an
> example of how make breaks when it's present.  In particular, it
> causes build of the compiler toolchain to fail if present, which
> keeps a complete system from building, on the alpha.

After looking over pr 1488, it's not at all clear to me why you
introduced a violation of the POSIX.2 standard (section 6.2.7.8) in
order to make a broken makefile work.

        foo: foo.o ../bfd/libbfd.a
                cc -o foo foo.o ../bfd/libbfd.a

        clean:
                /bin/rm -f foo *.o

make is functioning correctly; the way to fix this problem is to
either yank the dependency or to add an explicit dependency list and
rule for ../bfd/libbfd.a (after all, what *IS* supposed to happen if
it's out of date?):

        ../bfd/libbfd.a:
                cd ../bfd; ${MAKE} libbfd.a
# Or,           echo "Make in ../bfd before here."

Maxim: in a good Makefile, only source files should be without
(implicit or explicit) dependency lists and rules.

> It's worth noting that i'm aware of no other system on which the
> test breaks (i.e. on which 'make break' actually causes the make to
> croak), and i've tried SunOS, ULTRIX, and, DEC OSF/1...

Ultrix 4.2, SunOS 4.1.3_U1, and OSF/1 V2.1 all violate POSIX by not
having the .c.a rule.  So does gmake, incidentally.  (Admittedly, 4.2
is a pretty crufty version of Ultrix, but I don't have access to a
newer version.)

As far as I'm concerned, the POSIX.2 .c.a rule is a mistake, but any
Makefile that breaks because of it is probably doing something wrong.