Re: libgnustep-base split proposal

[Richard Frith-Macdonald]

On 22 Feb 2006, at 19:58, Jeremy Cowgar wrote:

> On Feb 22, 2006, at 1:29 PM, Richard Frith-Macdonald wrote:
>
> > I boggled when I read that ... then realised that my initial  
> > incomprehension was due to 20+ years experience programming on  
> > unix style systems ... it simply didn't occur to me that copying  
> > the library from one directory to another would be an issue for a  
> > developer (for a user, yes).  GNUstep is by no means alone in  
> > putting its libraries in its own directories ... many packages  
> > (ssh, postgres etc) use their own subdirectories.
>
> It's not hard, obviously. But, what about when you upgrade your  
> system, begin working on another system, copy from your development  
> box to your deploy box, upgrade your servers, etc... It becomes a  
> head ache trying to remember do this for this program, this special  
> thing for that program, etc...
>
> All I am getting at is it would be nice to have an objective C  
> library that installs w/no strings attached and allowed one to  
> program in Objective C w/o knowing a thing about the existence of  
> *anything* special or even the existence of GNUstep for that  
> matter. A simple libobjcbase.so, a /usr/include/objc and be done  
> with it.

OK ... but my point is we already have that ... you just have to  
install it where you want it.
But we don't install it where *you* want it by default.
So what's a good solution?  An alternative installer script to  
install it where you want it?  Automatic use of symbolic links so  
it's installed in the normal location but you can also find it in  
(say) /usr/lib?

> Then on top of all that, yeah, I give my program to John Doe and  
> say John Doe, you have to install gnustep-base, then copy this  
> folder to that folder, then move the includes from here to there,  
> then do this, then that, then compile my program, then copy it from  
> here to the /usr/bin and put it's libs in /usr/lib, etc...  
> Obviously *some* of that can be automated but... Now, John Doe is a  
> new unix user. It get's harder. Now he is a windows user and it's  
> really hard.

Surely you just give him the prebuilt package :-)
By the way, we gave considerable thought, when designing the new  
config system, to making it easy to provide standalone packages that  
people can just copy to their system and run without having to  
install anything.  This was specially intended for windows users.   
You just have everything in one directory, the library finds it's  
config by looking in the same directory it's in, and the config tells  
it where resources are.

However to address your eight stage example for the developer ...

> you have to install gnustep-base,
> then copy this folder to that folder,
> then move the includes from here to there,
> then do this,
> then that,
> then compile my program,
> then copy it from here to the /usr/bin
> and put it's libs in /usr/lib

You say *some* can be automated, but steps 2 to 5 are unnecessary, so  
it's

> you have to install gnustep-base,
> then compile my program,
> then copy it from here to the /usr/bin
> and put it's libs in /usr/lib

If you have a makefile, that's two stages

> you have to install gnustep-base,
> then 'make install' my program,

If we made an alternative install script to install just library and  
headers in /usr/lib and /usr/include, its

> you have to install gnustep-base using alternative install script xxx
> then 'make install' my program,

and the make file would omit -H and -L flags in the compile and not  
need to copy the library into place.

> I don't understand objections to having a great objc library that  
> people can use.

AFIK nobody has ever objected to that.

I'm just trying to find out exactly what your problems are so we can  
do something to avoid them ... and it's sounding to me like  we just  
need an alternative installation script to install stuff in the FHS  
locations ... something that's been on the roadmap for gnustep-make  
for quite a while now.