>>>>> "GD" == Garrett D'Amore <[EMAIL PROTECTED]> writes:
GD> Why so much for cmd? Well, the kernel and most (if not all) of lib already has ISA-specific build directories. Some things in cmd are structured that way, too, but an awful lot of stuff just dumps all the derived files into the same directory as the sources. Though come to think of it, maybe that's sufficient for your purposes. I was assuming that you'd want to allow for both SPARC and x86 binaries in the same workspace, so that you could easily do incremental builds. GD> Most of the code, though, can probably just do with changes to some GD> common Makefiles to adjust C flags. I suspect you'll need to tweak a lot of component makefiles so that they fit in whatever structure you choose for the common makefiles. I'd love to be proven wrong, though. GD> I -know- ARC review is required for interface changes, but I would GD> have thought there would have to have been some wider review of a GD> major change like what I'm proposing. What I did for the split into open and closed code was to write up the basics of the change and run it by some "likely suspects" for review. This included the lead ON engineer for Nevada, as well as the ON gatekeeper. I kept them informed of significant changes, and I made it easy for anyone inside Sun to review the changes in progress. The final code review was a pretty major undertaking, with developers from several areas reviewing separate portions of the changes. But a lot of that was just to make sure that my edits didn't accidentally break something. >From what I can see, most developers don't really care how the build works. They just want it to work, and they want it to be easy to do things like add/delete/rename source files. GD> Would it be worthwhile for me to start the process for the kernel GD> sources in a separate tree and post them somewhere for folks to look GD> at? Seems reasonable to me. Please be sure to provide a high-level overview of the changes, so that people don't have to deduce it from the code changes. mike _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
