Hello Yavor, all,
Am Fri, 17 Sep 2010 10:00:37 + (UTC)
schrieb Yavor Doganov :
> В Fri, 17 Sep 2010 10:36:08 +0100, David Chisnall написа:
> > On 17 Sep 2010, at 09:52, Yavor Doganov wrote:
> > They may have had input from some BSD developers, but it was never
> > adopted by any BSD systems.
Hello Nicola, all,
Am Fri, 17 Sep 2010 11:31:10 +0100
schrieb Nicola Pero :
> >>> If you configure GNUstep using the FHS layout on *BSD, it puts
> >>> stuff in completely the wrong place (it puts GNUstep.conf in the
> >>> wrong place with any configuration, unfortunately).
> >>
> >> For examp
On 17 Sep 2010, at 10:11, Richard Frith-Macdonald wrote:
> However, I think it would be good to maintain clear separation ... with
> CoreBase being a subproject, and continuing to be built as a separate library
> (so not quite the same as the existing additions subproject, which is
> actually m
Am 18.09.2010 17:15, schrieb David Chisnall:
> On 17 Sep 2010, at 10:11, Richard Frith-Macdonald wrote:
>> You could have the gnustep-base package build and install both by
>> default, but have an easy configure-time option to control exactly
>> what gets built/installed.
>
> Well, we'll need to i
Hi,
Native ObjC exceptions support was recently turned on by default in
gnustep-make. However this doesn't work with libobjc2, at least the
configure test. objc/objc.h is missing to eliminate the 'nil' warning and
Object in libobjc2 has an empty implementation. So either Object needs a
more comple
Hey Guys,
It would make live a little easier to do this for a number of reasons:
1) It would alleviate explaining to new people what gui and base
are... every time I talk about GNUstep I have to say "the gnustep
equivalent of AppKit/Foundation, etc..."
2) It would eliminate confusion between Core
Le 18 sept. 2010 à 18:23, Fred Kiefer a écrit :
Am 18.09.2010 17:15, schrieb David Chisnall:
On 17 Sep 2010, at 10:11, Richard Frith-Macdonald wrote:
You could have the gnustep-base package build and install both by
default, but have an easy configure-time option to control exactly
what gets b
On 18 Sep 2010, at 19:06, Quentin Mathé wrote:
> This seems a somewhat cleaner than including CoreFoundation.h in
> Foundation.h, but requires to import CoreFoundation.h explicitly when you
> depend on it. Not sure what's the best… I'd be tempted to favor Mac OS X
> compatibility.
Put this in
I'd suggest that libobjc2 could include a minimal Object implementation.
Having Object is handy to perform simple configure tests and both the Apple
and GNU runtime include a minimal implementation for that reason ... it would
make sense for libobjc2 to do so too ;-)
Else, if you have a patch to g
On 18 Sep 2010, at 19:24, Nicola Pero wrote:
> I'd suggest that libobjc2 could include a minimal Object implementation.
> Having Object is handy to perform simple configure tests and both the Apple
> and GNU runtime include a minimal implementation for that reason ... it would
> make sense for li
On Sep 18, 2010, at 11:31 AM, David Chisnall wrote:
On 18 Sep 2010, at 19:24, Nicola Pero wrote:
I'd suggest that libobjc2 could include a minimal Object
implementation.
Having Object is handy to perform simple configure tests and both
the Apple
and GNU runtime include a minimal impleme
Yes, I meant preface.h.in not prefix.h :-)
> Put this in Foundation.h
>
> #ifdef GS_EXCLUDE_COREFOUNDATION_HEADERS
> #import "preface.h"
> #else
> #import
> #endif
>
preface.h is always included (via GSVersionMacros.h and GSConfig.h). Not
including it might break something.. I think you'd jus
> Actually, this test will fail with Apple's Modern Runtime too - Object no
> longer implements +new.
> If you define __OBJC2__ (which recent Apple compilers do, you only get these
> two methods on Object:
>
> +class;
> -(BOOL) isEqual:anObject;
>
> +new is no longer allowed, so there is no def
Hi
I don't think it is really such an important question, especially if we
target distribution that will probably just automatically install all
three components.
2) It would eliminate confusion between CoreBase and the "base" which
is in the "core" of GNUstep i.e. CoreFoundation vs. Found
Hi
Well then, the packagers come close to being in my category (4) then ...
GNUstep should have a native setup for them so that the packages they produce
will just work for the end users.
Actually, I don't think that's ideal either ... we should assist packagers to
produce better packages ...
Hi,
FHS is a Linux 'standard', not a *NIX standard. Most *NIX variants use
something vaguely similar, but none use FHS. For example, on *BSD, GNUstep's
decision to put GNUstep.conf in /etc/GNUstep/ is incorrect - this location
should only be used for stuff that is in the base system. Third-
Hi,
In general, it is more or less irrelevant whether we like the FHS or
not. As long as GNUstep works with this layout, and Nicola was kind
enough to implement the revolutionary changes in gnustep-make 2.x
(which made our lives significantly easier), what the default layout
is doesn't matter (a
On 18 Sep 2010, at 21:00, Nicola Pero wrote:
> So, maybe a better solution would be to assume that (eg) @try/@throw/@catch
> works on Apple/NeXT
> runtime (ie, NeXT runtime AND __OBJC2__), and have a normal test using Object
> elsewhere ?
I seem to remember writing a post recently that descri
What does getting the CF stuff by default really hurt? If someone
doesn't want it then just don't use it. Making it optional just
complicates things a little.
On the other hand, I guess it just adds more weight to the library if
you know you're not going to use it in the first place.
GC
On Sat
19 matches
Mail list logo