> 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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev