Re: NSController and subclasses
I've restarted work on it again lately, so it's going to continue. I've uploaded the latest tarball to http://totorisu.sk/gscoredata.tar.bz2 If you want to, merge it into GNUstep SVN, but I would be happy if I could continue work on it ;-) As for the progress: so mere 15k line of code have been written so far and I estimate that it's going to cost once more that ammount to make it work well. The current status of both the Core Data framework and the Data Builder application is half-finished. -- Saso On 6/6/06, Gregory John Casamento <[EMAIL PROTECTED]> wrote: Wasn't Saso working on a core data clone? Would it be worth it to ask him if he can contribute this, since he recently said that he doesn't have time to work on it? -- Gregory John Casamento - Original Message From: Fred Kiefer <[EMAIL PROTECTED]> To: GNUstep Developer Sent: Monday, June 5, 2006 1:30:12 PM Subject: NSController and subclasses I am still trying to get the Books application to compile with GNUstep. Amongst many other things that are still missing, we also need NSController and the two subclasses NSObjectController and NSArrayController. All these classes have been added to AppKit in MacOSX 10.3 and extended in 10.4. GNUstep still doesn't have them. These classes need key-value coding and observing to be fully functional and NSObjectController also uses some classes from the coredata framework. This lets me doubt, if we really should put these classes into gui. What about having a coredata framework in the GNUstep SVN and add these classes as an extension to that? Any opinions? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSController and subclasses
Wasn't Saso working on a core data clone? Would it be worth it to ask him if he can contribute this, since he recently said that he doesn't have time to work on it? --Gregory John Casamento- Original Message From: Fred Kiefer <[EMAIL PROTECTED]>To: GNUstep Developer Sent: Monday, June 5, 2006 1:30:12 PMSubject: NSController and subclassesI am still trying to get the Books application to compile with GNUstep.Amongst many other things that are still missing, we also needNSController and the two subclasses NSObjectController andNSArrayController. All these classes have been added to AppKit in MacOSX10.3 and extended in 10.4. GNUstep still doesn't have them.These classes need key-value coding and observing to be fully functionaland NSObjectController also uses some classes from the coredataframework. This lets me doubt, if we really should put these classesinto gui. What about having a coredata framework in the GNUstep SVN andadd these classes as an extension to that?Any opinions?Fred___Gnustep-dev mailing listGnustep-dev@gnu.orghttp://lists.gnu.org/mailman/listinfo/gnustep-dev___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
NSController and subclasses
I am still trying to get the Books application to compile with GNUstep. Amongst many other things that are still missing, we also need NSController and the two subclasses NSObjectController and NSArrayController. All these classes have been added to AppKit in MacOSX 10.3 and extended in 10.4. GNUstep still doesn't have them. These classes need key-value coding and observing to be fully functional and NSObjectController also uses some classes from the coredata framework. This lets me doubt, if we really should put these classes into gui. What about having a coredata framework in the GNUstep SVN and add these classes as an extension to that? Any opinions? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling & distributing Tools
Am 05.06.2006 um 10:06 schrieb Michael Hopkins: 2) Distributing tools without headaches - packaging everything as statically-linked applications without the need for GNUstep directory structure/shared libs/GNUstep.sh The second big issue - and one that many people have asked about over the years. My current understanding is, the dynamic nature of the Obj-C language prohibits static linking of methods. This doesn't imply you wouldn't be able to create a single-file or at least a single-directory application. We simply want to send Tools out as completely self-contained applications that people can run from the command line on linux and win32 as if they were statically-linked C or C++ applications without any need for install scripts, extra directories, dynamic libraries/DLLs, sourcing shell scripts or changes to their startup sequence. It doesn't matter if the Tools are bigger than ideal. This is well understandable. However, neither Mac OS X nor GNUstep currently have a point-and-click solution in this area. I fear you have to start with "Hello World"-type apps and without makefiles to find out wether this is possible at all. 3) The need for GNUstep runtime e.g. gdomap, gdnc, Obj-C runtime? I am not sure what is required here and whether it is started automatically. Obviously, you need the Obj-C runtime. As this is a library, there's a chance to get it into your binary. For the deamons, there were some efforts recently to handle their non- existence more gracefully. Since most GNUsteppers work inside a full- fledged GNUstep installation, they wouldn't even notice casual dependencies. At the same time, they are likely (can't speak for all GNUsteppers) to accept getting rid of strong dependencies or to use them if available, only. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling & distributing Tools
Hi Michael, the one person to answer your mail is surely Nicola. I had my different goes at cross compilation with GNUstep, but as I was trying even more complicated stuff than you, I failed. One problematic bit has been left out by your description. When running configure the make system tries to find out settings for the target system. When cross compiling this cannot be done by executing test code to see if it works or fails. In that case it will either be necessary to run the configure script on the target system and copy back the result, or to run configure with a lot of manually set values. I would expect this wont be a big problem for your build environment, as the systems you are using are similar enough. One word of caution is needed for propel familiar with cross compilation. The terms build, host and target have different meanings in the GNUstep make framework to what they are normally used in the cross compilation world. Sorry, I cannot help you with any of your questions. I remember that when using static linking for GNUstep, you need to make sure to link in all the libraries statically. At least the ones using the objc runtime. But there are people out there with loads of experience in that area. We just need to bring together that experience and write it down in some document. Cheers Fred Michael Hopkins schrieb: > > > Hi all > > I am going to ask some questions here which have been posed at various times > in the past by both me and others (here and in other places), but they never > seem to get clear, authoritative answers for some reason. I am hoping that > this attempt will connect with the people who really know and can provide > solid advice and pointers for others to follow. > > We are hoping to wrap a bunch of our C math code into flexible interacting > objects and would prefer to use Objective-C/Foundation over C++/STL, but > unless we can get to the bottom of the following issues, we realistically > won't be able to do it. > > First, some clarification of what we are trying to achieve & how: > > - Building GNUstep Tools i.e. non-GUI Objective-C code that just relies upon > GNUstep-base <-> Foundation > > - Build machine is Ubuntu 6.06 amd64 with it's GNUstep development installs: > > gnustep-base-* 1.11.2-1 > libgnustep-base(& -dev) 1.11.2-1 > gnustep-make 1.11.2-1 > > The standard build environment is working fine. > > > Now the crux of this message: > > *** > 1) Cross-compiling without headaches - supposedly one of the main reasons > for gnustep-make. > *** > > Though we develop on Mac OS X (due to the lovely Xcode), the native target > for running code & distribution builds is GNU/Linux amd64. Our other two > targets are GNU/Linux i386 (i.e. 32 bit) and Win32 via mingw32. > > Our current solution for C & C++ code uses BSD make (pmake) for historical > reasons and calls different tools dependent upon command line options i.e. > > Target=amd64 -> > CC = /usr/bin/gcc > CFLAGS = -march=athlon64 -mtune=athlon64 -m64 ... > > Target=linux32 -> > CC = /usr/bin/gcc > CFLAGS = -march=pentium4 -mtune=pentium4 -m32 ... > > Target=win32 -> > CC = /usr/bin/i586-mingw32msvc-gcc > CFLAGS = -march=pentium4 -mtune=pentium4 ... > > Along with other supporting library & include makefiles this works well and > finds requirements/installs products correctly. > > Now - how to do this with GNUstep make? > >>From the INSTALL doc: > > Configuring for a non-flattened structure > - > > GNUstep is normally configured to support a single target/combo. If you > are interested in supporting more than one target and/or combo, it's > possible to configure GNUstep to use a non-'flattened' directory > structure. You do this by supplying the `--disable-flattened' argument > to configure. You might also want to supply the > `--enable-multi-platform' option. > >In a flattened structure, files are stored at the top-level rather > than in a `$(GNUSTEP_CPU)/$(GNUSTEP_OS)/$(LIBRARY_COMBO)' subdirectory. > > Configuring for a cross-compile target > -- > > By default when you run configure, it assumes that you want to create > executables for the same host that you are compiling on; however, the > GNUstep makefile package has been designed to support cross-compiling > just as easily as normal compiling. In order to add a cross-compile > target to the GNUstep makefile package, you must rerun configure for > that target and reinstall the makefile package. By rerunning > configure, the appropriate target settings are determined, and > reinstalling the makefile package installs the appropriate files for > that target. The target parameter is used to specify the target > platform for
Cross-compiling & distributing Tools
Hi all I am going to ask some questions here which have been posed at various times in the past by both me and others (here and in other places), but they never seem to get clear, authoritative answers for some reason. I am hoping that this attempt will connect with the people who really know and can provide solid advice and pointers for others to follow. We are hoping to wrap a bunch of our C math code into flexible interacting objects and would prefer to use Objective-C/Foundation over C++/STL, but unless we can get to the bottom of the following issues, we realistically won't be able to do it. First, some clarification of what we are trying to achieve & how: - Building GNUstep Tools i.e. non-GUI Objective-C code that just relies upon GNUstep-base <-> Foundation - Build machine is Ubuntu 6.06 amd64 with it's GNUstep development installs: gnustep-base-* 1.11.2-1 libgnustep-base(& -dev) 1.11.2-1 gnustep-make 1.11.2-1 The standard build environment is working fine. Now the crux of this message: *** 1) Cross-compiling without headaches - supposedly one of the main reasons for gnustep-make. *** Though we develop on Mac OS X (due to the lovely Xcode), the native target for running code & distribution builds is GNU/Linux amd64. Our other two targets are GNU/Linux i386 (i.e. 32 bit) and Win32 via mingw32. Our current solution for C & C++ code uses BSD make (pmake) for historical reasons and calls different tools dependent upon command line options i.e. Target=amd64 -> CC = /usr/bin/gcc CFLAGS = -march=athlon64 -mtune=athlon64 -m64 ... Target=linux32 -> CC = /usr/bin/gcc CFLAGS = -march=pentium4 -mtune=pentium4 -m32 ... Target=win32 -> CC = /usr/bin/i586-mingw32msvc-gcc CFLAGS = -march=pentium4 -mtune=pentium4 ... Along with other supporting library & include makefiles this works well and finds requirements/installs products correctly. Now - how to do this with GNUstep make? >From the INSTALL doc: Configuring for a non-flattened structure - GNUstep is normally configured to support a single target/combo. If you are interested in supporting more than one target and/or combo, it's possible to configure GNUstep to use a non-'flattened' directory structure. You do this by supplying the `--disable-flattened' argument to configure. You might also want to supply the `--enable-multi-platform' option. In a flattened structure, files are stored at the top-level rather than in a `$(GNUSTEP_CPU)/$(GNUSTEP_OS)/$(LIBRARY_COMBO)' subdirectory. Configuring for a cross-compile target -- By default when you run configure, it assumes that you want to create executables for the same host that you are compiling on; however, the GNUstep makefile package has been designed to support cross-compiling just as easily as normal compiling. In order to add a cross-compile target to the GNUstep makefile package, you must rerun configure for that target and reinstall the makefile package. By rerunning configure, the appropriate target settings are determined, and reinstalling the makefile package installs the appropriate files for that target. The target parameter is used to specify the target platform for cross-compiling: ./configure --target=i386-mingw32 make install GNUstep normally is configured to work with only one target. To work with multiple targets, you'll need to add `--disable-flattened' and `--enable-multi-platform' to the configure flags. Files for the different targets will not be overwritten when you configure and install the make package several times. ./configure --disable-flattened --enable-multi-platform --target=i386-mingw32 make install ./configure --disable-flattened --enable-multi-platform --target=sparc-solaris2.5 make install ./configure --disable-flattened --enable-multi-platform --target=alpha-linux-gnu make install OK, so this describes how to configure and build gnustep-make for multiple targets. Two questions arise from this: 1) Is there a standard way of specifying targets? When I tried it on our server the config files variously talked about x86_64-pc-linux-gnu, x86_64-linux-gnu, x86_64-unknown-linux-gnu... What is the standard specification for our three development targets and where is it specified? For instance, would this be correct for an initial install? ./configure --disable-flattened --enable-multi-platform --target= x86_64-linux-gnu make install ...and for the following installs? ./configure --disable-flattened --enable-multi-platform --target= i386-linux-gnu make install ./configure --disable-flattened --enable-multi-platform --t