On 6/7/07, James Carlson <james.d.carlson at sun.com> wrote: > Roland Mainz writes: > > Peter Memishian wrote: > > > "Uniformly for all AST libraries" isn't really uniform though, since > > > there's nothing inherently different about the AST libraries here -- quite > > > a few of our libraries consist of dozens to hundreds of source files. > > > > Mhhh... what should I do in this case ? AFAIK options are: > > 1. Leave the Makefiles as they are > > 2. Rewrite Makefiles to store all *.o files in a flat layout (e.g. > > single directory) [Needs 5-8days to write, compile and test (largest > > part is to watch my machines to compile the stuff... ;-( )] > > 3. Convert more libraries to the "put object files in subdirs"-solution > > [e.g. you pick victim(s) and I'll switch them over... :-) ] > > 4. Any other ideas ? > > I'm with meem on the earlier comment. I see no reason at all to > impose structure on the 'pics' directories in any libraries. It's > just a temporary repository of data, and not something that any human > ever needs to visit. Flat is fine. > > Adding logic to other libraries (as in 3) seems unhelpful. It adds > new complexity to solve a non-problem. (I think the fear _might_ be > having two .o names collide. I'd venture to say that if you have > sources with foo/bar.c and blah/bar.c both producing bar.o, then > you've probably got much bigger design and readability problems to > contend with than just the obvious file name problems.) > > Leaving these makefiles as they are (as in 1) isn't quite right, > because it means that this one area of the system is different from > the others. That makes it harder to maintain. > > So, as originally requested, I agree with (2). I suppose I could be > persuaded
I think Roland asked Peter Memishian for a resolution. It's up to him to decide whether the innovative (1,3) or the traditional (2) implementation is the right one. Irek
