RFC: library entry name collision

[Steve Fink]

I was beating my head on the wall yesterday trying to figure out why
an intlist test was failing on a freshly updated source tree. (I
rarely use 'make clean', because that's almost always just covering up
dependency problems.) I'll leave out the gory details, but the problem
boiled down to parrot/intlist.o and parrot/classes/intlist.o being
treated as identical by ar. Upon further reading, it appears that for
portability, we can only depend on the basename of ar entries.

So, what's the best approach to avoid this? For this particular case,
it's easy enough to just rename one or the other. (Or maybe all of
intlist.c should be inserted into intlist.pmc.) But generally, should
we have pmc in the name of all PMCs? Or should we make a separate
library for PMCs and any other major component? Is there some standard
trick I don't know about? Should we rebuild the archive from scratch
every time instead of replacing? (Would that be sufficient, or just
conceal the problem?)

[Mike Lambert]

> I was beating my head on the wall yesterday trying to figure out why
> an intlist test was failing on a freshly updated source tree. (I
> rarely use 'make clean', because that's almost always just covering up
> dependency problems.) I'll leave out the gory details, but the problem
> boiled down to parrot/intlist.o and parrot/classes/intlist.o being
> treated as identical by ar. Upon further reading, it appears that for
> portability, we can only depend on the basename of ar entries.

Two things...

First:
One dependancy problem that comes up all the time is that classes/Makefile
doesn't have any dependancies upon GENERAL_H_FILES. These .o files aren't
updated if I change parrot headers, etc. The best way to solve this is put
the logic into the base parrot Makefile, although that could make makefile
generation a bit more difficult.

Second:
intlist is not the only culprit. ./classes/key.c and ./key.c have a
similar problem.

Mike Lambert