First I have just run the new NLBconfig and all seems well. The output is even a little more readable.
"Jan Kok" <[EMAIL PROTECTED]> writes: > I forgot to mention, NLBConfig should be exectuable. Does CVS support > having files set executable when you check them out (as RCS and other > version control systems do)? If not, the user will have to "chmod +x > NLBConfig" after downloading. The Makefile action for rebuilding the > Makefile et al also assumes that NLBConfig is executable. I'd prefer if we don't go down the exectuable bit route. diff(1) and patch(1) don't support it. Plus it is one more thing to modify. The one decent way I have seen to do this is to have a script that sets the permisions on everything, that you can just run, and that might be worth doing. > > So why not have NLBConfig.py? Just wondering. > > No deep, subtle reasons, I just wanted to simplify the way it was called, > "NLBConfig ..." instead of "python NLBConfig.py ..." > But that requires that the script be set executable... :-) And it isn't currently. And I don't see ./path/to/NLBConfig being much simpler than python ./path/to/NLBConfig.py. O.k. While we are looking at this, the biggest problem with the build system currently is that it doesn't handle aggregating multiple pieces into a single rom image very well. This is what the payload command is ``supposed'' to handle but it doesn't quite get it right. Further even with payload we may miss at least one important case. Right now I build 2 linuxBIOS images one a backup/fallback image, that I very rarely flash. And another normal image that I flash regularly, and is my normal image. For this I have two config files. And I just have a top level makefile that coordinates the two seperate builds and handles the rest for me. If we can get the build sorted for this kind of case I'd appreciate it. If you want a snapshot of my build directory to see what I'm doing just tell me. Eric
