] Based on early looks at this, I think that Jambase needs to be broken ] up, with a small set of general purpose rules and actions, and then have ] the user include a language specific set of rules/actions. ] ] (General purpose being the support for sub-jamfiles, install, copy, ] that sort of thing. Language independant.) ] ] I've also thought that maybe the parts of Jambase that customize it or ] configure it for different hardware/OS's be broken up in similar way. Then ] the jambase itself could include one of these at run time, based on the OS ] variables already there. ] ] This would potentially give a number of files to make up the jambase, but ] I think would be easier to manage. ] ] If we just keep adding machines/OS combos and languages to it, its going ] to get out of hand, if its not there already. (Its a pretty tough read ] for a new user now.)

I agree with Hunter on all points. The existing jambase, while certainly impressive, is more than I (and I presume others) can absorb. I would prefer a more modular (structured?) approach. This is important to me, because I'm constantly changing target operating systems (and target processors, for that matter). I would prefer a top-level jambase with all the common rules/actions, followed by OS and/or target specific conditionally "included" rules/actions. (Have I been redundant? Is that what Hunter just said?)

Any others of like mind?