Re: GNUstep make problem packaging a framework

[Nicola Pero]

> > 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).

Ok - now I see what you mean - you were thinking that we would add an
entry in LD_LIBRARY_PATH for each framework installed on the system.

Well - no - we won't do it :-) - absolutely not - I was wanting to remove
the symlinks to actually *simplify* the LD_LIBRARY_PATH, not to complicate
it.

As I said in the other email, I don't see any reasonable workable
workaround to help the runtime linker find the framework libs, the
symlinks seem the best available way, so unless someone has some brilliant
idea, we'll keep the library symlinks.

But - but at least I'd like to move the symlinks inside the standard
libraries directory - that will simplify a bit both linker options, and
LD_LIBRARY_PATH.


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

Yes - I noticed these problems when trying gnustep on csh a week ago - so
you probably agree with me that moving the libraries framework links to be
with the other libraries is a good thing, since it will downsize a lot the
LD_LIBRARY_PATH - I think it should downsize it enough to work on csh.


===


I'm not even sure I want to completely remove header symlinks at this
point, since it wouldn't simplify as much because the library symlinks
would still be there, and I would have to add new code to manage the
xxx_FRAMEWORKS and locate the frameworks on disk ... hm.

No - at this point my plan is the following - 

 * the Library/Headers directory will be removed

 * all the symlinks to the framework header dirs will be built inside
   xxx/Headers - the same place where the library headers are

 * all the -Ixxx/Library/Headers flags will be removed from the compiler
   command line.


 * the Library/Library directory will be removed

 * all the symlinks to the framework shared libs will be built inside
   xxx/Libraries - the same place where the standard shared libraries are

 * all the -Ixxx/Library/Libraries flags will be removed from the
   linker command line, and from the LD_LIBRARY_PATH.


 * I will add to gnustep-make source code full comments explaining the
   issues and why we use symlinks and why in this way


I think the benefits are -

 * command lines of both the compiler and linker will be simpler.

 * frameworks are more integrated with the rest of the system.

 * LD_LIBRARY_PATH is much simpler, hopefully might work on csh.