> 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
