[Greg Banks] > 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.
Agreed.. > So now we assume BK? What's next, Python 2.1? Touch�. No, my point was not that we can assume BK, but that we can assume the developer is willing to install whatever tools he needs to get the job done. I think the assumption is valid, assuming the developer has some choice in the matter - i.e., do not dictate a specific SCM or even a specific version of gcc (though there is a fairly limited range of acceptible gccs). > This would be the case if the build process were simple and linear > and consisted of just cobbling together a combined source tree and > then building a kernel image. But in my experience it comprises a > number of loops where I go back and fix simple compile errors > (either my own or the latest IDE breakage from the mainline kernel) > and do a partial rebuild. A solution where I have to cobble > together 174 MB of kernel source every time I fix a one-line compile > error is not useful. Another good point. You seem to be full of those. Anyway, the "cobble together" script will most likely build a symlink tree, not a whole separate copy, so you probably wouldn't have to rebuild it *every* compile. At least, if I were writing an ad hoc shadow tree preprocessor, that's how I'd do it. Then when you are just fixing one-liners, you aren't adding or removing files from the tree so you don't rebuild the link forest. > Here's part of a brand new checkout: Ah, I wasn't thinking 'cvs co / export', I was thinking 'cvs update', which is sane. If you have a brand new checkout, you probably don't have a preexisting set of object files yet, so I'm not convinced that you can actually break your compile this way. (I do agree it's a design bug in cvs.) Peter ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
