Ron says, > the main thing that hits me is that I think eric would like to preserve > the cpuflags file. So I'd like the changes absent that, unless there is > something else Eric would like to see changed.
Thanks, Ron. I just created a new target directory, ran the latest NLBConfig.py, and did a make. There was a make warning about missing cpuflags, but it then immediately generated cpuflags and passed the CPUFLAGS value to the compiles. So, it works OK the _first_ time. BUT, I then edited my top-level config file and re-ran make (without running NLBConfig manually). make re-ran NLBConfig, regenerated the cpuflags file with the OLD values, ran NLBConfig again, then recompiled files and so on, using the OLD CPUFLAGS values. So, the current make/cpuflags scheme appears to be broken. I don't like the cpuflags file for a couple other reasons: 1. It appears unnecessary. As far as I know, only Makefile uses it. And my solution to generating CPUFLAGS runs (always) during the first pass through Makefile, thus giving high confidence that CPUFLAGS will always be up-to-date. 2. People might mistakenly get the idea that cpuflags is a source file and go edit it, thus wasting their time and confusing themselves further when wierd things happen. (cpuflags is derived from Makefile.settings) Eric's only comments (a few weeks ago) about my cpuflags removal were: >Was it really broken. It works here and I haven't heard complaints. >GNU make is pretty smart about building makefile depenencies. >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. So, since it really appears broken, and Eric didn't seem to have any other objection to the change, I will start the merge of my changes (including the cpuflags file removal) with the latest NLBConfig.py at SourceForge. I will ask that Ron or Eric give it a try when ready and check it in if it's OK. Longwindedly yours, - Jan
