Re: XML idea

[Kazunobu Kuriyama]

> >>>Putting the source code in a subdirectory, and extending the
> >>>automatically generated documentation to mark such stuff as
> >>>MacOS-X compatibility code would be quite enough to make
> >>>me very happy,
> >>>
> >>I like that idea as well.
> >>
> >However, this does not address the issue of what to do with crap classes 
> >which were poorly designed on Apple's part...Would those be included? 
> >excluded? See the problem? This doesnt fix the problem. It makes it more 
> >complicated.
> >
> I think making a subdirectory for that purpose rather helps PortabilityKit
> project.  If such a directory exists, we could untar ProtablitiKit.tar.gz
> in the source of -base/-gui in such a way that a directory which is a sibling
> of the subdirectory is created there. And if the configure script 
> detects the existence of PortablitityKit, the build process could be 
> configured so that the implementation given in the kit is used. (This 
> may remind you of old libstdc++'s.)
Personally, I would have to absolutely vote against this idea since I 
believe it's FAR too complicated and confusing, and I also feel that a 
line should be drawn in the sand between PortabilityKit and GNUstep. 
They're separate projects for a reason. What I see as a possibility is, if 
someone downloads the entirety of -core and then runs ./configure 
--with-PortabilityKit, what would happen automagically is the following:

1. (OPTIONAL/NOT NECESSARY) A disclaimer/warning is displayed which states 
that PortabilityKit is not part of the GNUstep project.
2. PortabilityKit is CVS-fetched from its savannah page into a 
PortabilityKit directory in the root of -core.
3. PortabilityKit is built (as a framework, optimally) along with the rest 
of core.
4. PortabilityKit is installed as a framework in 
$GNUSTEP_SYSTEM_ROOT/Frameworks or wherever is best suitable.

> Also, it is expected to make the maintaince of the both projects easier.
I completely disagree.
> However, one problem still remains unfixed.  I'm afraid not a few users
> are likely to fail to understaind the implication of such a hierarchy
> of directories.  Anyway, I think it's good for the both sides.
Exactly, and this is why I believe that what I suggested above is a 
better, cleaner, and easier to understand solution.