Re: gnustep-make experiment

[Matt Rice]

On 2007-01-24 22:05:26 -0800 Nicola Pero 
<address@hidden> 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