I spent the last day getting parrot running under Borland. The attached patch is whats need to get linking and running make test on both Windows/Borland and Linux/gcc. I'm not sure if its ready for inclusion in the tree, but I want some feedback on the approach.
The main problem is that Borland can't build a single static library (at least I did not find out) with two files of the same name. But there are some name clashes: intlist.o and classes/intlist.o or stacks.o and languages/imcc/stacks.o. I solved this by seperating libparrot in three partial libs: classes/classes.a containing all object-files of classes/ ; languages/imcc/imcc.a containing all object-files of imcc and blib/lib/libparrot.a for all the rest. (This names need cleanup; shouldn't they all go to blib/lib?). classes/ is still build by its own Makefile, this should be integrated in the root-Makefile, but thats another story.
Next problem is library interdependence. classes.a depends on libparrot.a and libparrot.a depends on classes.a. This complicates linking a bit. The gnu linker does not revisit previous files so the link line has to contain something like libparrot.a classes.a libparrot.a A new configure variable parrot_libs takes care of this
Since no one else commented, I'll give you my two cents. I think there are 4 other options in addition to your proposal:
1) Find out for sure if Borland has a way to build this into a single library, if you're not 100% certain. Don't know if there are any Borland experts on the list.
2) Build separate libs, but only under Borland.
3) Rename the files with duplicate names so that they don't conflict--this might be worth doing anyway.
4) When building under Borland, make copies of the offending files under different names, and build those. (e.g., make a copy of languages/imcc/stacks.c called imcc-stacks.c, and build that instead)
I'd say that (4) is the cleanest (it only affect the one problematic environment, and you get to keep a single library everywhere), but as I said I think (3) might be useful anyway (just to make it easier to refer to files in conversation). Option (3) is also dead-easy, but we'd lose cvs history for the renamed files.
Having multiple libs isn't the end of the world, but it would be a shame to have to do it because of a particular compiler/linker quirk.
JEff
