[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Legacy applications and headers
From: |
Helge Hess |
Subject: |
Re: Legacy applications and headers |
Date: |
Fri, 19 Mar 2004 17:38:44 +0100 |
On Mar 19, 2004, at 4:40 PM, David Ayers wrote:
Now as Skyrix seems to have abandoned libFoundation (and I have no
idea if GDL2 would have ever worked with it) we might have a true
binary situation (ie. either GNUstep or Cocoa).
For the foreseeable future SKYRIX will use libFoundation and it is in
no way "abandoned". Indeed this is a must, because SKYRIX customers
have at least two years of basic maintenance by German law (so
libFoundation will be actively supported for at least this timeframe).
I think GDL2 should work just fine with libFoundation, but this
combination is probably not very interesting. New GDL2 developments
should start with either Cocoa/GDL2 or gstep-base/GDL2, not lF/GDL2.
OpenGroupware.org on the other side will use gstep-base - once the port
(not just SOPE, but the complete OGo) properly works and is as fast as
with libFoundation. Of course it will continue to run on libFoundation
for the foreseeable future as well (there is no point/reason in
breaking compatibility with libFoundation, its done, bugfree and just
works), but this won't be the default.
Now, to the real topic:
Personally (from a lF point of view) I don't care about the patch, its
a speed optimization for OSX and has no significant effects on
compilation performance on ix86/Linux platforms.
Obviously the way it is now is technically correct (#ifdef
NeXT_Foundation_LIBRARY), because this optimization only applies to
Cocoa, but I see ZNeK's point about configuration and think that it is
valid.
The question is the actual define. I would suggest
#ifndef __APPLE__
since on Apple platforms the precompiled headers are available. Of
course this slows down compilation with gstep-base on MacOSX (unless
gstep-make/gstep-base can make use of the pch compiler?), but I wonder
whether this is an important case?
As discussed before with Nicola an
#ifdef GNUSTEP
really refers to the gnu-gnu-gnu library combo which has nothing to do
with the inclusion of header files and
#ifdef GNUSTEP_BASE_LIBRARY
is also semantically incorrect (since this is true for any alternative
Foundation library).
So I would discourage to use one of them.
Summary: the proper solution would be a "-DGNUSTEP_WITHOUT_PCH=1"
define generated by the gstep-make configure script (this would also
take into account that even gstep-base might have a PCH compiler in the
future!). Until this is available the __APPLE__ define is probably the
best match to the original intention.
regards,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
- Legacy applications and headers, Marcus Müller, 2004/03/19
- Re: Legacy applications and headers, David Ayers, 2004/03/19
- Re: Legacy applications and headers, Adam Fedor, 2004/03/19
- Re: Legacy applications and headers, Marcus Müller, 2004/03/19
- Re: Legacy applications and headers,
Helge Hess <=
- Re: Legacy applications and headers, Nicola Pero, 2004/03/19
- Re: Legacy applications and headers, Marcus Müller, 2004/03/19
- Re: Legacy applications and headers, Helge Hess, 2004/03/19
- Re: Legacy applications and headers, Nicola Pero, 2004/03/19
- Re: Legacy applications and headers, Adam Fedor, 2004/03/19
- Re: Legacy applications and headers, Nicola Pero, 2004/03/19
- Re: Legacy applications and headers, David Ayers, 2004/03/19
Re: Legacy applications and headers, Markus Hitter, 2004/03/19
Re: Legacy applications and headers, Nicola Pero, 2004/03/19