[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-make experiment
Re: gnustep-make experiment
Sun, 11 Feb 2007 11:58:14 +0100
Icedove 184.108.40.206 (X11/20061220)
Matt Rice wrote:
On 2007-02-10 17:34:59 -0800 Nicola Pero
The only objection i've heard from gnustep.pc is "Its not the way
GNUstep stores information".
Here is a refresher --
1. it adds an external dependency upon which *everything* would depend
an entirely optional dependency, people could continue sourcing GNUstep.sh.
2. it is slower
-make is not a bottleneck...
for example on my machine....
-make building base here takes 2 minutes 3 seconds...
make when base is already built takes 2 seconds..
where adding this stuff to make would be 0.006th of a second per
invocation of pkg-config/gnustep-config
this argument is hogwash.
3. it is designed for something else (which adds complexity)
It does exactly the same thing gnustep-config.sh does.
that adds no complexity...
4. it requires rewriting and redesigning stuff with no clear advantages
there are clear advantages...
now I can add stuff to configure for things *using* gnustep-make which
attempts to see if
GNUstep libraries exist.
there could be a way to bootstrap gnustep-make to "just work" without
any gnustep specific
The objection i have with GNUstep.conf is it isolates gnustep from
the rest of the world.
I find that objection vague. Can you explain the practical meaning of
"it isolates gnustep from the rest of the world" ?
It's a text file in /etc/GNUstep.conf containing something like
it can be set by --with-config-file when configuring make.
If this is done, GNUstep can find GNUstep.conf without setting
GNUSTEP_CONFIG_FILE... GNUSTEP_CONFIG_FILE is
provided to override the location of /etc/GNUstep.conf if you
didn't change the default GNUstep.conf location.
I refuse to rely on a feature which
a) 99% of the time is fine.
b) the 1% of the time works unless your relying on GNUstep.conf being
theres no way to reliably locate it if the caller was not generated by
That's a chicken and egg problem with every configuration. If I compile
apache in /opt the configuration of apache will live in /opt/etc/apache,
or /opt/etc/httpd, which is not the system default location. Because I
choose it to be different, hence the need for a configure option to
point to the config file.
The same goes for the .pc files. Ever tried to build the pkg-package
supported libraries in non-default places (like in
/usr/GNUstep/System/Library/Libraries)... then you also have to set the
PKG_CONFIG_PATH variable to make make it all happen.
Same goes for ldconfig... it per default only searches the FHS default
places. Hence the need for /etc/ld.so.conf... but what if you configure
ldconfig for /usr/GNUstep/System/Configuration as the /etc directory.
What I am trying to say is that every system that you invent to do
"automagic" for paths, libraries etc. will rely on defaults and needs
environment vars for the exceptions.
I doubt you will ever find a package that solves all problems.
Just my 2 cents.
Re: gnustep-make experiment, Nicola Pero, 2007/02/10
Re: gnustep-make experiment, Christopher Armstrong, 2007/02/10
- Re: gnustep-make experiment, (continued)
- Re: gnustep-make experiment,
Dennis Leeuw <=