> > 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...
Indeed, I'd never do a commit without doing a build -- my suggestion implied deferring the commit until all of my feedback has been handled. > > 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 ?) Yep. > 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 ? Well, it's valuable, but it doesn't address the core concern that we've created something that's different from established practice without a really good reason -- and "cramped" object file directories seem like a low-priority issue (if an issue at all). Anyway, this is a minor complaint and I don't want to blow it out of proportion, so I'm going to leave this one up to you -- though of course I hope you choose consistency :-) -- meem _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
