gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release schedule


From: Richard Frith-Macdonald
Subject: Re: Release schedule
Date: Sat, 5 Apr 2003 05:04:09 +0100


On Friday, April 4, 2003, at 11:38  pm, Chris B. Vetter wrote:

In that particular case, I wasn't even using anything in NSApplication,
it just got included via <AppKit/AppKit.h>

Apart from that, you will get a hole slew of missing interfaces, syntax
errors, eg. in NSWindow.h.

So how is it supposed to make sure it's compatible, if some parts
"inside" depend on parts, that are defined "outside" the scope?

What am I missing?

I'm not sure that you are.

The STRICT_OPENSTEP definition is there for two purposes -
1. To make it easy for developers to produce code which only makes use of the
OpenStep  API (without any extensions) by having the preprocessor remove
anything non-standard which the developer might use by accident. Thus allowing
development of code which should run on OPENSTEP.
2. To mark the headers so that autogsdoc knows which classes/methods belong to the original OpenStep spec, so it can identify them in the generated documentation.

Both those aims require careful placement of #ifdefs ... the first being more tricky because (as you noticed) it has to deal with non-standard data types being
used for ivars of standard classes.

I've just been through and altered the gui headers enough to get applications
to compile with STRICT_OPENSTEP defined.  I was disappointed by the
amount of alterations I had to do that, and Im certain that the STRICT_OPENSTEP
stuff is not in use throughout the headers as it should be :-(
Hopefully this is not the case in the base library, where I think it's all correct.

For portability issues (use of STRICT_OPENSTEP, STRICT_MACOS_X, port to
windows, runtime compatibility options etc) the GNUstep developers *MUST* depend upon the people using the system to fix problems, as there aren't enough core developers to test all this sort of thing. With the best will in the world, errors will continually creep in and the people who need a non-standard system have to
keep a check on it to stop that sort of creep.

Given the state I found the headers in ... my impression is that nobody is actually using STRICT_OPENSTEP for the first purpose ... If nobody is trying to use it for producing OPENSTEP compatible applications, should we be bothering with the
first usage at all?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]