> Suppose we have split declarations for derivations or defaults of > symbols that are shared across architectures. It would then be > locally convenient for configuration maintainers to move these > declarations from the top-level rules.cml file piecemeal to rules > files in different arch subtrees, or elsewhere. > > The problem is that it then becomes globally difficult for someone > reading the rulebase to know what the derivation or default behavior > of a symbol actually is. Different pieces of the behavior could be > scattered all through the rulebase.
One of the systems I worked with used a top level Makefile which read a `Makeconf' file (both of them together were probably < 20 lines) which defined what the build was going to be. The build could be characterized by a tuple like [unix, solaris, sparcv9] or [unix, linux, i386] or [vxworks, productname, ppc]. There was directory that housed all the make rules and the order of sourcing them was from the most general to the most particular (for example, common rules first, then unix rules, then linux rules and so on). This, along with some other ways or organizing the source code lead to a a situation where the build rules were scattered (well, they were all in separate files at the top of the source tree in a separate directory for just the make rules). It worked pretty nicely, most of the platform/arch maintainers do local stuff in their own files and things work ok as long as the global or common ruleset was not broken. One of the keys insights (for me at least) from that was that, in build systems, enumerating the variables and getting their behavior from a lot of scattered files is better than conditionals in one big file. A lot of the default behavior came from the common rules, in the above system. -Pragnesh _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
