On 18 Jun 2010, at 02:55, Jonathan Wolf wrote: > Thanks for the reply David, > > I apologize for my lack of correct terminology - I did mean just > Foundation (as in, NSObject, NSDate, etc.) and .app bundles. > > The idea that this is sparked off from is basically how one would take > ObjC, in a minimalist form, and port it over to another environment - > equally the same issue if you were to take it from iPhone to desktop > (say Windows/MinGW) or, probably another avenue to be explored next > year, iPhone to Android (if estimates of the Android market overtaking > iPhone stay true). > > Having done years of C++, I've developed quite a hatred for all things > C++ in nature, and having gone from a strong C++ background to an ObjC > background, I have been absolutely amazed that it hasn't gotten more > wide reception. Either rate, I think one of the issues was that ObjC > was so intertwined to Apple, and GNUstep aims to break that - and this > is a very good thing imho. > > So I am trying to leverage the Foundation runtime best I can, but in a > minimalist form as possible - so aiming at a one file .so/.dll is the > goal really. I think that my original question may be a bit off since > what I am really interested in trying to make happen is so that going > through a GORM/GNUmake makefile like system (producing an .app > bundle), while interesting, is not necessarily the avenue wanting to > be took - mainly just pushing out a libobjc.so/.dll and > libnsfoundation.so/.dll would be the most ideal route. > > Looking at some of the tie-in architecture on the bundle's plist and > other such thing - especially in relation to NSUserDefaults - I am > getting the idea that it may not be so easy. > > So maybe the real question is, how do you make GNUstep's foundation > layer a shared object, compilable via -lnsfoundation gcc linker flag > (or similar), and avoid the entirety of an .app bundle?
The procedure for doing that would be (when building from source): 1. download gnustep-make, unpack the .tar.gz into a directory, go into that directory, type 'configure', then 'make install' 2. download gnustep-base, unpack the .tar.gz into a directory, go into that directory, type 'configure', then 'make install' Alternatively, download and install a binary package (if one is available for your system) or use one supplied by your system. The shared library will be there. Having the foundation (gnustep-base) built as a single shared library is what GNUstep does (as David said, someone's obviously been telling you an awful lot of rubbish). Now, to run a gnustep program using the gnustep-base shared library requires nothing but the library, but along with the shared library there's obviously other stuff installed: 1. Headers ... you obviously need those to build software using the libraries 2. GNUstep.conf config file (there are compiled-in defaults in the library, but this allows you to configure basic stuff ) 3. The gnustep-make system ... use this to make it easy to build programs ... not needed to run the resulting program of course. See http://www.gnustep.it/nicola/Tutorials/WritingMakefiles/ 4. timezone files ...these are provided for consistency since different operating systems use different timezone information (there's no real standard) and supplying a common set for all gnustep apps allows you to be sure that those apps behave consistently across different software platforms. If you are targetting a single platform (or in almost all cases even on different platforms) it makes no real difference whether you use them or remove them to force native timezone information to be used. 5. XML DTDs etc ... needed for processing specific XML documents, not otherwise 6. Various programs to make your life easier. None of them are needed for you to use the library but: a. gdomap is needed to run as a daemon IF you are using Distributed Objects between separate machines (it's not needed for DO between programs running on the same machine) b. gdnc is needed to run as a daemon IF you are using distributed (inter-process) notifications. This is needed by the NSWorkspace class in gnustep-gui (AppKit). The NSUserDefaults system is the mechanism for storing user preferences and configuring options for programs ... if you run a gnustep program it will create a local defaults database for the user. But ... if you really, really don't want persistent storage of user preferences, you can turn it off (in GNUstep.conf) so that NSUserDefaults operate in memory and don't store information on disk. Since people almost always *do* want NSUserDefaults, the option of turning it off is not general knowledge. mostly it's only the rare individual who actually reads through documentation who is aware of it. I would advise using NSUserDefaults rather than turning it off, since it's great for all those cases where you would otherwise need to code your own configuration file parser for your tool. So, if you intend to use/tolerate NSUserDefaults, then gnustep-base is built the way you want it 'out of the box' If you want to disable NSUserDefaults storage on disk, then you would need to go through the extra stage to turn it off. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
