Matt, thanks for your comments. I understand your desire to centralize the configuration, but there is an actual reason why GNUstep.sh is a pure shell script. ;-)
It's a machine-independent program that can be in a machine-independent directory and that can then be used to bootstrap the fat binary system. :-) If you rewrite it in C and then compile it, it's no longer a machine-independent program. You need the fat binary system to manage the bootstrap system itself - things get more complex, the bootstrap is no longer an easy process. ;-) So to me rewriting it in C is not a simplification - it's a complication. >From your comments I believe the issue is not entirely clear, probably my lack of a good explanation, so I'll try to explain it. I admit I'm no longer enjoying this discussion though, as it's very tiring, looks very much like a perpetual flamewar against me and my GNUstep week has already been very stressful. So please keep that in mind. >> We managed to get rid of all C tools in gnustep-make in October 2006, and >> that >> was a good step in terms of simplification: no longer having to worry about >> the location of tools in fat binary dirs when using gnustep-make's own tools, > > this is expected to be in the PATH, there is no need for that Possibly ... after you have configured/bootstrapped your GNUstep configuration. But yours (the one you're proposing) would be *the* config program. You call that program to know where the System Tools directory is, for example. So you call it before you have bootstrapped your GNUstep configuration! In fact, on a fat system you call it precisely to set up your PATH. And because it's a compiled executable, it *must* itself go in a fat binary directory, since you are expected to be able to mount from the network (or unpack from a big gzip file) your fat gnustep-make installation, and it must work, having different compiled executables for all the different machines. I don't see how this is simpler than what we have. What we have is composed of a shell script (GNUstep.sh) that is always in the same location (GNUSTEP_MAKEFILES). You just source that script, no matter on which situation you are, there are no bootstrap issues because the same interpreted shell code works on all machines, reads the config filesystem layout file directly from the shell (which is trivial as it's simply included), determines or guesses your machine type, merges the filesystem layout information with the cpu/os/library-combo information, and can easily set up your PATH, LD_LIBRARY_PATH and such, and voila, your environment is bootstrapped, and now you can find and use any sort of compiled tools and programs in your PATH, navigating the otherwise confusing fat binary directories. So the same code with no tweaks, nothing to think of, nothing to understand, it just works on all machines and in all situations. I find that really simple. In other words, we need an architecture-independent program to bootstrap the fat binary configuration, so we use a shell script. Natural choice, as shell scripts are interpreted and you can run them on all machines. Why rewriting it in C and then having to worry about how to support multiplatform installations ? We're introducing new problems and new complications. We could work on solving those problems, but then the feeling is that we're just inventing new problems and then trying to solve them, which could be fun, but there are probably better ways to spend our little GNUstep development time! ;-) Thanks _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev