[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-make experiment
From: |
Nicola Pero |
Subject: |
Re: gnustep-make experiment |
Date: |
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
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
Re: gnustep-make experiment, Nicola Pero, 2007/02/18