[EMAIL PROTECTED] writes: I've cc'd to the list because there are other people watching and I hate having conversations twice...
My personal bandwidth is oversubscribed as it is... > > Ideally I'd like to have 2 tools. > > Build-Makefile > > Build-Configuration > > > > And with everything being derived from Makefile.settings and regenerated > > we don't have a problem seperating things out. > > Are you saying that Makefile.settings should be the only "source" file for > configuration, and the top-level config file that is now passed to NLBConfig > would be derived from Makefile.settings? At this point it is an idea, not a firm opion. But there may be some advantages to build the Makefile once, and then be able to tweak Makefile.settings if you need to change an option. Even if we don't really make the distinction user visible, having it in the build system can be handy. Sort of in the do one thing and do it right category. > The current scheme make sense to me: There is a top-level config file that > can be easily altered by the user. Makefile is derived from the config > files, and it controls the overall flow or "shape" of the build. > Makefile.settings should contain parameters that don't affect the Makefile, > but do affect the .o and later files. Right. > Do you want to have a way to specify > parameters that _do_ affect the makefile? If so, NLBConfig could be altered > to allow such parameters to be set in the config files (I think [N]LBConfig > might have previously allowed this, based on a few lines of "unreachable > code" that I removed.) As far as parameters I think I have broken everything out fairly well. It is just that everything all happens with one tool. Being able to have a nice user interface to the variables, and what they mean (The things that get set in Makefile.settings). Could be extremely handy for end users. Right now it can be difficult to track them. A UI isn't the entire solution as the backends need to be cleaned up a little and do more autoconfiguration instead of being hardcoded everywhere. But having people other than the developers being able to find the options would help. > If you can explain what you want, and can convince me that it is an > improvement, I might try to implement it. > > > And you missed the number one detail on my todo list. Add header file > > dependencies so we have complete dependency information. > > Do you have an idea about how you would want to do that? There are a few > tools (mkmf, etc.) that can figure out what the dependencies are by reading > the source files, but I'm not all that familiar with them and not sure what > would best suit your needs. I'm not at all certain. gcc -MMD would probably do the trick. It doesn't need to be anything fancy, it just need to do it :) The other thing we need in th build system while I'm thinking about is a build stamp. Something like cvs checkout date/time, + build #. I'd say version number but so far we have been to lazy to implement one in linuxBIOS. > Thanks for your feedback! Welcome. Eric
