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

[David . Ayers]

I inadvertently started a new thread [technically speaking] because I
haven't found a way to configure my mail client to behave. I'll try to
whatch out for that in the future. But on the other hand my topic is more a
mater of cross-compiling GNUStep core rather than the mere include/import
discussion.

Shortly after I pushed the "send" button yesterday I realized the potential
flaw in my suggestion. Dividing the base for example would mean that
baseExt would depend on base. This means base wouldn't be able to use
anything from baseExt. This could be a serious problem.

But light sleep last night also brought another suggestion. Given that the
makefile system does (will) support subprojects, the division could be done
there: (I'm not sure if sharing of headers among subprocts is a
framework-only feature or if this could also be done for a library.) All
Core Projects could be divided into:

- CocoaComp.subproj
contains current Cocoa API

- Openstep.subproj
contains Openstep compatibility (I take it Apple has or will depricate some
parts of the OPENSTEP Spec. So if we want to stay compatible, will have to
keep this code and guard it with STRICT_OPENSTEP or the like.

- GNUStep.subproj
contains GNUStep additions. All the good stuff that GNUStep-App developers
like to use but can't today if they want to cross-compile on Cocoa.


Beeing in the same Project, CocoaComp.subproj could use GNUstep-features
and GNUStep-features could use Cocoa.subproj. If we would also supply a
Cocoa-Makefile and PB.project-file and the likes that use Cocoa-Frameworks
instead of CocoaComp.subproj...
supplying:
- GNUStep.subproj would have to guard the usage of implemtation specifics
(ie access to instance variables) with ifdefs and use accessor methods for
Cocoa.
- GNUStep.subproj would either include for #CocoaComp and #import when
using Cocoa (Actually I wouldn't have problem always #import-ing until
Apple changes thier mind some day, but do as you will, I don't and
shouldn't care. As long as headers are always safegarded from multiple
inclusions, but this was never up for discussion anyway.)

then maybe GNUStep-Core could become cross-compilabe!!!

Other Implecations:
Gorm could run under Cocoa, but would produce Cocoa/GNUStep-dependant
.gorm-files. But then again, any App creating archives using the NSCoding
mechanism is inherently Lib-Combo-Dependant. This should be true today.
(ie. .gorm-files created with libFoundation should be incompatible to the
ones created with base, given that the encoding methods differ somewhere.)

So how would you create a "cross-comilable" ie plattform independant
GORM/NIB-File?
The alternative would be some XML-Archive or rather XOA (XML Object
Archive). [I would have to check with the OMG if some similar spec already
exists.] (Of course gmodel would seem to be the prime prototype.) This
would introduce an NSCoding alternative (GSXOACoding ???) It would have to
code formal attributes that can be used to recreate the state of an object
independant of it's implementation. This would also be the encoding to be
used in Cocoa<->GNUStep-Core comunication model. It might be compressed to
reduce size and that data could be PGP/GPG-encrypted for "privacy" either
by the user or a framework/library. This could by used by people creating
propriatay code (like Apple or better yet by all those companies that are
now writing Cocoa-Code and may want to port to GNUStep one day!!!) The
encoding must of course be public and we should find a way to declare it in
the header files. (But this is already going very far.)

But how about it. is there any good reason to make GNUCore
cross-compilable?
- GNUStep apps would get Cocoa-cross-compile for (almost) free!
- GNUStep-core could be used by other companies (like OMNI or the like)
maybe leveraging some of the influence we could have on Apple's future
development.

Well what do you think?
I might even consider buying a mac to help out in this.
(but don't quote me on that, yet. My Linux isn't even running yet. But I'm
working on it. Right now my problem is a blown power unit and a lack of
diskspace, but both are beeing remedied as we "speak".)

Later,
Dave