Re: GNUstep make problem packaging a framework

[Nicola Pero]

Hi Mirko, 

I've thought about this quite a lot and now I've some good plan of what to
do.

> > > When I try to package a framework I have built using GNUstep make into
> > > a RPM, I get the errors appended below. Apparently RPM does not like
> > > the symbolic links that get created inside the bundle to designate the
> > > current version... How do I fix / work around this?
> >
> > good spot - packaging of frameworks is broken without obvious fix.
> 
> What is the problem with rpm ?

The symlinks are not built in a relocatable way - which might be fixed,
but I've thought about it and I think I have a better more radical
solution - implement xxx_FRAMEWORKS to list all the frameworks needed by
the tool/application/yyy you are compiling, and having gnustep-make
contain code to add the appropriate -L -I -l for that framework when the
tool/application/yyy is compiled ... without any symlink.

In general, I like the idea that all what is needed to use the framework
is inside the framework directory ... it's a bit of a hack that you need
symlinks from outside to be able to use the framework.  Apple has a
-Framework option built in their linker I think to specify frameworks to
use - we can probably do with a xxx_FRAMEWORKS option to gnustep-make and
gnustep-make will process that option, adding the appropriate -L -I -l to
use the framework(s) - in a certain sense, emulating what apple's linker
does.


> > Links to framework headers will be done from the standard location of
> > headers, /opt/gnustep/System/Headers/, where all other headers go - we'll
> > get rid of putting framework headers in a different dir (for no reason at
> > all) - I'll remove /opt/gnustep/System/Library/Headers and take advantage
> > of that to simplify all make code and all compiler command line
> > invocations.
> 
> If I understand correctly you would move symlinks in other dirs. Is it right ?

No - I've thought more about it and changed my mind - my intention now is
to remove the symlinks completely.  That would simplify creation and
installation of frameworks, would fix RPM building, and would be much more
elegant and clean - everything needed to use the framework is in the
framework directory.

To link against a framework, instead of adding -lMyFramework on the
compiler command line, you will add

MyTool_FRAMEWORKS = MyFramework

gnustep-make will use the xxx_FRAMEWORKS variable to add both

-L/home/nicola/GNUstep/Library/Frameworks/MyFramework.framework/Versions/Current/ix86/linux-gnu/gnu-gnu-gnu
-L/opt/gnustep/Local/Library/Frameworks/MyFramework.framework/Versions/Current/ix86/linux-gnu/gnu-gnu-gnu
-L/opt/gnustep/Network/Library/Frameworks/MyFramework.framework/Versions/Current/ix86/linux-gnu/gnu-gnu-gnu
-L/opt/gnustep/System/Library/Frameworks/MyFramework.framework/Versions/Current/ix86/linux-gnu/gnu-gnu-gnu

and -lMyFramework (and -I options, but I'll discuss about it later).  A
further improvement might actually check where the framework is on disk,
and add just a single -L - to the location of the framework on disk.  I'm
not yet implementing this as I'd like to start with something working and
only later on add optimizations - but nothing prevents us from adding it
later on (it's actually my idea that the real final thing will be able to
locate the framework and add a single -L -I -l - this would be like the
apple linker).

I've already done this and it works fine and I think it's quite better.  
I've not yet committed to CVS because I'd like to do the same for the
headers ... but that doesn't work out-of-the-box yet, and here I'm happy I
can ask you so you could help me to decide what to do -

Say that you want to use the framework MyFramework.
You specify

MyGreatApplication_FRAMEWORKS = MyFramework

Now gnustep-make has to add an appropriate -I directive.
The obvious one would be 

-I/opt/gnustep/System/Library/Frameworks/MyFramework.framework/Headers

but this will not work, because you include the headers as in

#include/import <MyFramework/A.h>

so the header will not be found, because the current framework code is
putting them into

/opt/gnustep/System/Library/Frameworks/MyFramework.framework/Headers/A.h

while the linker will search into

/opt/gnustep/System/Library/Frameworks/MyFramework.framework/Headers/MyFramework/A.h

My question is - would it be ok to modify the framework directory so that
headers are installed as in 

MyFramework.framework/Versions/A/Headers/MyFramework/A.h

rather than 

MyFramework.framework/Versions/A/Headers/A.h

?

In this way, passing the natural -Ixxx/MyFramework.framework/Headers to
the linker will work.

Otherwise we need to add yet another symlink for the Headers - this one
usable by gnustep :-), something like

MyFramework.framework/Includes/MyFramework
 --> MyFramework.framework/Versions/Current/Headers/

and then gnustep-make will add the include directive

-I/opt/gnustep/System/Library/Frameworks/MyFramework.framework/Includes

and it should work.
(but it's quite confusing to have Includes vs Headers ...)


> I hope you haven't the intention to move the _contents_ of the
> framework in other dirs.

Sorry - not sure what I said or what you understood :-), but I've no
intention to move /opt/gnustep/System/Library/Frameworks from where it is
(since it is in the same place as Bundles, which is quite appropriate) nor
to extract anything from the .framework directory, actually I'd like to
remove the symlinks so that all the framework contents are inside the dir.

If I said anything different about moving Library/Frameworks from where it
is, which I might have, I changed my mind after thinking about it in
detail.  Sorry for that.