[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-make experiment
Re: gnustep-make experiment
Sat, 17 Feb 2007 02:31:20 +0100 (CET)
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
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
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
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
>> 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
it before you have bootstrapped your GNUstep configuration! In fact, on a fat
you call it precisely to set up your PATH.
And because it's a compiled executable, it *must* itself go in a fat binary
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
for all the different machines.
I don't see how this is simpler than what we have. What we have is composed of
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,
the config filesystem layout file directly from the shell (which is trivial as
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
compiled tools and programs in your PATH, navigating the otherwise confusing
So the same code with no tweaks, nothing to think of, nothing to understand, it
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
configuration, so we use a shell script. Natural choice, as shell scripts are
and you can run them on all machines. Why rewriting it in C and then having to
how to support multiplatform installations ? We're introducing new problems
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
probably better ways to spend our little GNUstep development time! ;-)
Re: gnustep-make experiment, Nicola Pero, 2007/02/18