In article <29145.812156501@BALVENIE.PDL.CS.CMU.EDU> Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU (Chris G Demetriou) writes:
>Christos 'fixed' pr 1488 with a a commit to make/suff.c, then undid it
>with:
>
>> Modified Files:
>> 	suff.c 
>> Log Message:
>> Revert previous suffix fix. If the .a suffix is present and a .c.a rule is
>> there, then the rule should be applied. This is the correct behavior.
>
>
>So, is it correct that the test 'program' that i supplied _should_
>break (when 'make break' is done)?  or was it just that the fix you
>tried wasn't the right one?
>
>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...
>

The SunOS make equivalent of sys.mk /usr/include/make/default.mk,
defines a .c.a rule, but does not put .a in the known list of suffixes.
Pmake does not allow you to define a suffix rule without defining a
suffix [I'll have to look at the Posix manual to determine which is the
correct behavior]. If I add .a to the list of suffixes in
/usr/include/make/default.mk, then 'make break' breaks on SunOS too.
Same for gnu-make: given the same set of rules I get the same
behavior.

Therefore the bug is not in the pmake engine itself. I am not sure what is
the meaning of having suffix rules around without the suffix being in the
list of suffixes... Do they get activated once the suffix gets added to the
list of suffixes?

Currently there is no suffix treated specially by make; adding a special
rule for .c.a: suffix application does not seem right to me. I'd rather
rename the file, or remove the rules. Or even make pmake accept suffix
rules that don't have a suffix currently defined. 

christos