Re: NSController and subclasses

2006-06-05 Thread Sašo Kiselkov

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

2006-06-05 Thread Gregory John Casamento
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

2006-06-05 Thread Fred Kiefer
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

2006-06-05 Thread Markus Hitter


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

2006-06-05 Thread Fred Kiefer
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

2006-06-05 Thread Michael Hopkins



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