[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libgnustep-base split proposal
From: |
Richard Frith-Macdonald |
Subject: |
Re: libgnustep-base split proposal |
Date: |
Thu, 23 Feb 2006 00:31:26 +0000 |
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.
- Re: libgnustep-base split proposal, (continued)
- Re: libgnustep-base split proposal, Jeremy Cowgar, 2006/02/19
- Re: libgnustep-base split proposal, Riccardo, 2006/02/19
- Re: libgnustep-base split proposal, Richard Frith-Macdonald, 2006/02/22
- Re: libgnustep-base split proposal, Jeremy Cowgar, 2006/02/23
- Re: libgnustep-base split proposal, Richard Frith-Macdonald, 2006/02/22
- Re: libgnustep-base split proposal, Jeremy Cowgar, 2006/02/23
- Re: libgnustep-base split proposal,
Richard Frith-Macdonald <=
- Re: libgnustep-base split proposal, Yen-Ju Chen, 2006/02/24
- Re: libgnustep-base split proposal, Helge Hess, 2006/02/24
- Re: libgnustep-base split proposal, Alex Perez, 2006/02/25
Re: libgnustep-base split proposal, Gregory John Casamento, 2006/02/23