[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
