Sam Ravnborg wrote: > > On Wed, Jun 26, 2002 at 12:36:11AM +1000, Greg Banks wrote: > > I think the problem of Makefile bits in shadow trees is really > > quite difficult. Keith's solution of pre-processing Makefiles and > > Makefile.appends from all the shadow trees into a combined Makefile > > doesn't handle all the cases but is the best attempt I've seen so > > far. > Keith's approach is the only working attempt to handle shadow trees > outside a modern SCM tool. > So obviously it is the best so far.
Actually the SuperH port uses a sort of poor man's shadow tree, where we get a shadow tree from CVS and then use a script to symlink the shadow tree's files into the main tree. I understand this approach was copied from another port, although I can't remember which. > > So now we assume BK? What's next, Python 2.1? > People are not forced to use BK whatsoever. Last time I looked there > were still regulary patches available at kernel.org - where does this > come into the picture. Sorry, this was a rhetorical question, I'll try to be clearer next time. > But on the other hand, if people want decent support for parrallel > development then a modern (not CVS) SCM tools is perferable. Be that > BitKeeper, PRCS, arch or whatever. Some people, I believe a significant number, are still stuck in the CVS dark ages. CVS still has some advantages, e.g. you can get a free, public, remote CVS repository at sourceforge.net for basically zero effort. I won't attempt to argue that CVS is better than BK (although I might argue its more practical than PRCS for some tasks). But the reality is that it's still out there, it's mature and it's quirks are well known by those who use it. The reality is also that some people have no SCM at all, our beloved leader being one these until recently. > If people refuses to use existing tools solving a specific problem > then thay are on their own. I see no point in integrating this deep > into kbuild because some people do not want to, or do not understand > how to do parrallel development using a proper SCM tool. The problem is that when you're dealing with a combined tree built from source published by multiple people with varying SCM setups (including none at all) you soon end up working with the lowest common denominator of all those SCM setups, i.e. none at all. Hence, to get all the benefits of (say) BK, we *all* need to be running BK. Until we reach this state of Nirvana, tree management will be very very painful for some people. > This does not stop any attemp to make a simple wrapper that > creates and maintain a BUILD_TREE. > To check timestamps and link accordinly should not take too much time, > at least not at the second run. Ok, why don't you and Peter Samuelson get together, create such a thing and we can compare it against kbuild2.5? If it's simple and a win, great! Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. ------------------------------------------------------- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
