Re: GNUstep Native Framework Support

[Nicola Pero]

> Hello everybody
> 
> I know there have been tons of discussions and flames on this topic, but this
> time I have a solution for it. For details, please read
> http://openspace.adlerka.sk/NativeFrameworks and tell me your opinion: is it
> worth bothering about further, or just blow the whole thing in the wind. And
> please don't stone me if you don't agree with the details...

Thanks ... it's an interesting idea ... and nicely done! :-)

I can see a few problems with this approach though --

 * ObjC software is not always invoked from the command line ... eg if
your ObjC software is a package (linked to some frameworks) that you want
to load inside a program written in another language (typically Java or
Python), you can't execute any prior script to set up the library path to
match the exact frameworks linked into the code you're loading;  you'll
just be loading the ObjC code using C calls to the linker libraries and
running it.  That makes everything lot more complex in this case -- I
suppose all language interfaces would have to have custom code that would
actually manually load all the required frameworks using the linker
libraries ?  That would be quite messy.  Currently, instead, all this is
done automatically by the linker and is really nice. :-)

 * In some cases, LD_LIBRARY_PATH is ignored on Unix.  For example, by
tools that can be run as root by any user (setuid).  For those, the only
possible solution is having symlinks and then running ldconfig. :-(

 * The recent trends in GNUstep users are that we should try avoiding
shell/C wrappers and relying on LD_LIBRARY_PATH and other such variables.  
Most people are more worried about being able to deploy the software so
that it runs out of the box and can't be considered as friendly as native
applications, rather than about frameworks being more "real". ;-)

 * Wrappers are slow.  We used to have wrappers for all our ObjC tools,
but that way whenever you write a command-line in ObjC you'd get penalized
a lot compared to a native C tool.  You can't match the speed of a native
C tool such as 'sed' or 'grep' if you have wrappers -- the wrapper itself
will require at least an additional process creation, which is a
considerable overhead for a light command-line tool.  So we managed to
remove the wrappers, and nowadays writing ObjC command-line tools should
be possible and they should be reasonably comparable, in speed, to native
C tools. :-)

I don't mean to stop the debate though, and not necessarily to discourage
you.  Maybe we could still have it as an option if people like it. :-)

Let's hear what other people think ;-)

Thanks