[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep make problem packaging a framework

From: Helge Hess
Subject: Re: GNUstep make problem packaging a framework
Date: Tue, 22 Jan 2002 17:21:09 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020117

Nicola Pero wrote:
If you use 4 frameworks (which is already a lot of framworks in my option)

In my understanding under MacOSX I'm supposed to use a framework instead of a library in basically all cases. In SKYRiX we have:

address@hidden:~/mdev/SkyrixRoot> find . -name "*.so"|wc --lines

shared libraries which would turn into 50 frameworks ;-)

BTW: The NeXTstep csh isn't even able to hold the "normal" GNUstep LD_LIBRARY_PATH !!!

you have the same number of -I switches as now.  If you use 10 frameworks,
you have 6 -I switches more than now.  I don't particularly see the
problem - if you use 10 frameworks, you also have 10 more -l options on
the command line when you link ... never heard someone complaining about
that ... apple/next has a -Framework option more for each framework on the
command line ... it's the same here, you have a -I option more for each
framework - where's the problem ?

I have no problem with compiler options, can be as much as you like ;-) The problem are shells and environment variables (LD_LIBRARY_PATH).

Not to say that I seriously doubt any point about command lines being too
long for the shell, since when I link gnustep-base, the linker command
line is the following -

A: you are probably using bash which allows for pretty large lines
B: the problem are environment variables, not program paths/parameters

this linker command contains many more than 100 arguments.  So if a shell
can process that Ok, I don't see how adding 5 or 10 (if you are using 14
frameworks, a huge number) -I to a compilation command (which contains few
arguments compared to this linker command) could hurt.

I don't think it hurts. I'm concerned about PATH/LD_LIBRARY_PATH.

SKYRIX Software AG -
Web Application Technology for Enterprises

reply via email to

[Prev in Thread] Current Thread [Next in Thread]