[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML idea

From: Alex Perez
Subject: Re: XML idea
Date: Thu, 8 Jan 2004 17:46:06 -0800

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
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
"Error of opinion may be tolerated where reason is left free to combat it."
--Thomas Jefferson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]