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 ? > > > > Your choice... > > I'm curious about the 5-8 days part; surely you can build the individual > libraries fairly quickly and iterate towards something that will work > before kicking off a nightly, right?
That's what I did for http://bugs.grommit.com/show_bug.cgi?id=253 - I skipped the full rebuild to hurry up and as a result the tree now doesn't build because the *DEMO*-rule changes cause lots of trouble (this happens when I start to sloppy testing... ;-( ) ... ;-( The original estimation for the "5-8 days" was based on these assumptions (warning: raw guessing using wild numbers running around in panic): 2 full rebuilds on an Ultra5 (2*2 days, assuming I find a bug/problem in the first run, fix this issue and then re-run a new build) weekend (2 days, can be sacrified on demand (except babysitting)) 1/2 night to craft the patch 1/1-1 day to re-run all test suites The hacking part may not be the time-eating one - the full rebuild needs lots of time and the manual testing needs some time, too. ... but right now I am trying to craft a patch for the build failure caused by http://bugs.grommit.com/show_bug.cgi?id=253 blindly based on April's feedback and pray that this works, otherwise I need a new tree which needs lots of time on this xx@@@!!-snail... ;-( > Seems like we could save the nightly > for after I have a chance to finish my review of the other Makefiles, > since you'll have to do another one after that anyway. Uhm... I strongly disagree in this case... I belive that it's better to make sure that the tree (even this prototype tree) builds all the time after doing commits with no exception. Otherwise other people like April who use the tree can't continue their work until I have cleaned-up the mess I caused... > Anyway, my preference is for (2), but I'm willing to agree to (1) if > you're really sold on what you have (Offtopic: English question: "sold on" == "belive in", right ?) Techinically I think it is a better solution than cramping everything into one flat dir. In theory we could even save the mkpicdir rule by letting the compiler rule itself create the subdir on demand (the original prototype code had a custom rule which did exactly that (based on the assuming that "mkdir" and "dirname" are shell builtins and therefore won't cause trouble for the build time (and mkdir(2) is an atomic filesystem operation and following accesses are (likely) cached by the DNLC))) ... ... but I can understand your concern... without "precedent" in OS/Net for such a thing my own position is pretty much weak and listing other projects like Mozilla.org as precedent will likely not work, right ? > and are sure it will take that > long to do (2). Well, it's only my snail-like build machine and the manual testing of libast&&co. which cause the trouble for me... AFAIK there are much faster machines out there (e.g. April delivers feedback after ~~four hours which means she has access to a build machine which is at least twelve times faster than this xx@@@!!!) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
