Re: GNUstep make problem packaging a framework

[Helge Hess]

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
     50

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.

Greetings
  Helge
--
SKYRIX Software AG - http://www.skyrix.com
Web Application Technology for Enterprises