Re: XML idea

[Kazunobu Kuriyama]

Alex Perez wrote:

> > > > > 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.
Some people prefer the above; the other not.   I'm not sure.

> > Also, it is expected to make the maintaince of the both projects easier.
> I completely disagree.
I can't understand this point.  Because you want to make the two project
distinguishable, your project should not depend on GNUstep's direcory
hierarchy; GNUstep can go its own way.  Could you explain more why GNUstep
shouldn't take such a hierarchy?  The subdirectory seems to help you
purge what you call craps.

- Kauznobu Kuriyama