Re: gnustep-make experiment

[Nicola Pero]

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