(Topic from late January, sorry for taking so long)

> At the moment, sys/arch contains many assembler files, some of them with
> names ending in ".s" and some in ".S".  As far as I can see,
> emitrules() config(8) emits the same rules for assembling both of these
> (being invocations of ${NORMAL_S}, but emitsfiles() only puts ".s" files
> into ${SFILES}, which means that "make depend" doesn't check dependencies
> for ".S" files.

This message will probably turn out to be redundant, but in case anyone
didn't know it already: unixy compilers default to spitting out ".s" files
into the current directory when you ask for assembly source output.

	gcc -S foo.c		# writes foo.s
	cat foo.s

So under NO CIRCUMSTANCES should we have EVER used ".s" as the name of any
valuable source file.  It's just begging to be accidentally blown away some
day when a developer is toying around with C versions of the same code that
might happen to have the same base name.

I like .S  --  I know of one commercial toolchain (the Green Hills one) that
also supported CPU arch extensions, like ".m68" ".386" ".ppc" ".mip" and such
-- but when they got to ".sh" there was much wailing and gnashing of teeth.

Todd Whitesel
toddpw @ best.com