On 2007-01-24 22:05:26 -0800 Nicola Pero
<[EMAIL PROTECTED]> wrote:
but my main problem with GNUstep.sh isn't actually technical at all,
its the very first thing potential developers are going to see, so
will be
the first impression,
and imho gives the impression of being strange because it is
uncommon for a
build system to depend on environment variables to function.
I looked at your patch and I understand what you're trying to do ...
it's good
stuff and it's good to have this discussion, but let me first insist
in
claryfying something ... ;-)
The build system does not depend on GNUstep.sh at all. We spent years
working on removing that dependency, and it's no longer there! :-)
It's not advertised much yet, but it will be clearly advertised in
the
release note
of the forthcoming gnustep-make release. GNUstep.sh is obsolete in
the
default
setup.
You only need to set GNUSTEP_MAKEFILES and everything will work
(assuming you
have your tools in your path, and libs in your linker paths). This
is all
already implemented on trunk! :-)
Yes, but you still need to do something before running make, which is
what this patch is
mostly about.
You only need to set GNUSTEP_MAKEFILES. This is already on trunk!
Once that's clear, we can discuss the patch ;-)
I see two good ideas in the patch ...
1. I guess you are suggesting to put a makefile somewhere in the make
search
path and
change all makefiles to include it so that you can compile without
even
setting GNUSTEP_MAKEFILES. I like the idea of not having to set any
variable
to compile,
but I also see a couple of obvious cons --
it would be more difficult
to switch between different gnustep-make installations (at the
moment, you
can easily
switch by just changing GNUSTEP_MAKEFILES!),
Not really, the patch allows you to switch installations by setting
PKG_CONFIG_PATH
and specifying --with-pkgconfig-path to configure to tell it where to
put gnustep.pc.
The difference being instead of always having to configure it,
configuration is made to
be something only people who need that behaviour have to do.
and we need to ask everyone on
the planet
to change their GNUmakefiles, and in a way that will likely make them
stop
working
unless you use a recent gnustep-make - they won't like it. So we
need to
think a lot and make
sure we make the right choice before we do it. Eg, if you have to
modify
your make
include path to make this work, then you may as well ask people to
set
GNUSTEP_MAKEFILES. ;-)
Well i still don't find this argument very compelling,
for some undeterminable amount of time we need to source GNUstep.sh
or set GNUSTEP_MAKEFILES to compile old software,
of course it isn't forwards compatible so new software wouldn't
compile on older installations
2. you're suggesting to have a script that can help ./configure
scripts
examine the filesystem for GNUstep softtware. That sounds good, but
having
the script return GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT etc seems
the wrong
thing to do -- these are the variables that make it difficult to
switch to
Linux FHS and we are trying to move away from them! In fact, we have
already moved away from them. As shell variables, they are obsolete
and
should not be used!
Yeah, the stuff stored inside gnustep.pc is by no means required to
contain SYSTEM_ROOT/LOCAL_ROOT etc
If these things change (as indeed it seems they have) so should the
gnustep.pc, it was mainly intended as
a demonstration to show how i was imagining this working
anyhow yeah if e,g, $GNUSTEP_SYSTEM_ROOT/Library/Libraries is no
longer reliable this will need to change
Finally, your gnustep.pc seems a duplicate of
/etc/GNUstep.conf! ;-)
yeah it is,
its a duplicate of a home-brew method, to use a relatively standard
method
though GNUstep.conf is available only to GNUstep, only GNUstep knows
where it exists
because its path is configurable. I assume you can set
GNUSTEP_CONFIG_FILE (or something)
to tell GNUstep where to find it, but this doesn't help in finding the
deafult which is used if
GNUSTEP_CONFIG_FILE (or something) doesn't exist.
If the information in it is only attainable by GNUstep and no longer
available in environment variables
(or reliable if we can no longer $GNUSTEP_XX_ROOT/Library/Libraries
for AC_CHECK_LIB)
then i wouldn't consider it a complete solution
anyhow If i understood correctly, i thought GNUstep.conf was initially
always hard coded to /etc/GNUstep.conf
and was intended to make stuff like GNUstep variables available to
shell scripts and what not, then
/path/to/GNUstep.conf became configurable at some point and it lost
this purpose, and the purpose then
was limited to configuration of GNUstep variables at runtime --
replacing the environment variables...
but maybe I was wrong with that assumption
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev