Re: XML idea

[Alex Perez]

On Jan 8, 2004, at 5:06 PM, Kazunobu Kuriyama wrote:
> > > 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;
And it would not. My suggestion is simply a way to ease the  *BUILDING* 
of  GNUstep+PortabilityKit at the same time. PortabilityKit would still 
compile and install down to its own Framework. This is just about 
convenience/ease of use.
>  GNUstep can go its own way.  Could you explain more why GNUstep
Yes, it is of course free to do as it wishes.
> shouldn't take such a hierarchy?  The subdirectory seems to help you
> purge what you call craps.
Well, for starters, many "mediocre" classes, such as NSToolbar, also 
make changes to other classes. I dont really see the point of putting 
Cocoa classes which GNUstep has decided to implement in a separate 
place, I guess. Added complexity, no gain.
--
Alex Perez
aperez@student.santarosa.edu
"Error of opinion may be tolerated where reason is left free to combat 
it."
--Thomas Jefferson