[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML idea
Re: XML idea
Fri, 09 Jan 2004 09:44:49 +0900
Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1
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:
>>>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
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.)
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
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.
Exactly, and this is why I believe that what I suggested above is a
better, cleaner, and easier to understand solution.
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.
RE: XML idea, Mondragon, Ian, 2004/01/07
RE: XML idea, Mondragon, Ian, 2004/01/08
Re: XML idea,
Kazunobu Kuriyama <=
RE: XML idea, Mondragon, Ian, 2004/01/09
Re: XML idea, Kazunobu Kuriyama, 2004/01/09
Re: XML idea, Jason Clouse, 2004/01/10