Oops, I replied to Eric instead of Reply-All. Here is what I said: ----- Original Message ----- From: <[EMAIL PROTECTED]> To: Eric W. Biederman <[EMAIL PROTECTED]> Sent: Thursday, December 06, 2001 1:32 PM Subject: Re: NLBConfig and other changes
> From: Eric W. Biederman <[EMAIL PROTECTED]> > > [EMAIL PROTECTED] writes: > > > - The "include cpuflags" in the Makefile was broken: namely, the > > > cpuflags file was generated long after it was needed. So I eliminated > > > the cpuflags file and used a different mechanism to compute CPUFLAGS. > > > Yet another way to do this would be to just have NLBConfig write > > > "CPUFLAGS := ..." in Makefile.settings. > > > > Was it really broken. It works here and I haven't heard complaints. > > GNU make is pretty smart about building makefile depenencies. > > I may check it again sometime, but what I remember is that the _first_ time > make was run after doing NLBConfig (no existing cpuflags file), make would > warn about the missing cpuflags file, then would make it later on. So next > time make was run, it would (I _assumed_) use the previously made cpuflags > file. Sort of one step behind. > > I must admit my solution is a bit obscure. I had to study the make > documentation and fiddle with it for a few hours to find something that > works. Make wasn't designed to be a scripting language. Or be readable. > :-) > > > 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? > > I'm afraid I don't see a clear advantage to that scheme, compared to what is > done now. Could you explain? > > 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. 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.) > > 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. > > Thanks for your feedback! > - Jan > >
