Antwort: Re: import vs include Re: Porting autogsdoc to OSX

[David . Ayers]

Greetings,

This import/include thing got me thinking about GNUStep, compatibility and
portablity...

I thought, the intent of GNUStep is to:
- supply an LGPLed version of the OPENSTEP-spec
- supply an allow (not force) developers to write GNUStep/OS X compatible
code

if I understand it correctly, it is not intended to
- supply an alternative plattform to compile arbitrary OS X code (ie Cocoa
Apps)
- supply libraries/bundles that will allow Cocoa apps to use
GNUStep-Extensions

this means, if someone wants to write cross-compilable code one must use
the common denominator. Something developed for Cocoa does not compile
under GNUStep for free and something developed for GNUStep doesn't compile
on Cocoa for free.

The #import/#include issue seems to currently imply that if you want
cross-compilable code, you must use #import directive yet one still should
guard headers to allow the usage of #includes when creating
libraries/frameworks.

Now, how could/should one include ;) GNUStep goodies (ie everything in
GNUStep which is not covered by the OS X API like GSDOC) in a Cocoa app? It
would be nice if this code were in a compatibility bundle/library, but this
would need to use #imports (at least on OS X) and would contain lots of
code associated with base today. This would then allow most GNUStep apps to
compile using Cocoa (Foundation/AppKit).

The real question seems to be, does it make any sense to invest so much
work into seprating this code into a seperate library/bundle, just so that
GNUStep apps can be ported to Cocoa easily? Or does it suffice to have base
compiled under OS X? I must say I haven't formed an opinion yet, but I'm
also sure the implecations reach very far. It wouldn't just be matter of
base, but would imply any framework/library which clones a Cocoa API must
be devided in a pure API library and extension library.

In effect:
base    - would implement OPENSTEP and Apples (current) API
baseExt - would implement all other things
        - would need to compile with base & OS X/Foundation [Headers] (ie
use #imports on OS X and use the correct header name)

gui     - would implement OPENSTEP and Apples (current) API
guiExt  - would implement all other things
        - would need to compile with gui & OS X/AppKit  [headers] (ie use
#imports on OS X and use the correct header name)

gdl     - would implement Apples EOF API
gdlExt  - (I think you get the picture)

GSApps would import all *Ext headers. In this configuration on GNU/Linux
one could use base/baseExt, on OS X one could use Fondation/baseExt but one
could also use base/baseExt on OS X!

Now the next question! What does GNUStep mean when it says it is or it's
Apps are portable/cross compilable? Does it mean that one is able to
compile on GNULinux and OS X? Or does it mean that one is able to exchange
the Cocoa/core libraries?

How far does compatiblity go?

Hmm... AppOSXCocoa.app running on OS X wants to use DO to connect to
AppGNULinuxGNUStepCore.app. And pass it an Object!
Will this ever be possible? Well maybe if you could recompile
AppOSXCocoa.app to AppOSXGNUStepCore.app.

But the AppOSXGNUStepCore.app will not be able to DO to other Cocoa apps!
It couldn't even Cut&Paste and Drag&Drop to other Cocoa apps! Does this
alone mean that GNUStep apps must use Cocoa to be integrated with other
Cocoa apps on OS X? Here I recall the was discussion a while back when
talking about X integration and the Pasteboard! (Wow, I think this is the
showstopper and I formed my opinion. We should divide the libraries and be
able to compile CORE-Extensions agains Cocoa frameworks.)

To be able to C&P, D&D and DO between Core and Cocoa, creating a
PlattformIndependantDOExtension-bundle and get your arbitrary
AppOSXCocoa.app to load it seems the was to go. (This sounds real
intersting but also next to impossible especially if effeciency is
requirement, but never the less very interesting.)

I think what is needed is a clear specification of what GNUStep wishes to
achieve when it speaks of compatiblity. And this should be clearly defined
on the Website. Flame me if I missed it and it was there all the along.

Thanx 4 your time,
David