Re: Making autogsdoc a separate package

[Helge Hess]

On Dienstag, 22. Juli 2003, at 18:51 Uhr, Nicola Pero wrote:
> I see gnustep-base as the basic foundation library for Objective-C, 
> very
> much like libc is for C.

Finally Nicola is going to become a libFoundation convert ;-) No, 
really, I pretty much agree.

> Similarly, when you download gnustep-base, you should get the basic
> Objective-C foundation library, with the mimimal set of tools to use it
> (gdomap, defaults, and few others).

Well, actually for OGo even things like "gdomap" are unnecessary 
complications of the environment and I would be very happy if they 
could be disabled. But this is a different case, being required for 
Foundation API compliance.
(I guess it's sufficient to place gdomap in a separate RPM/Deb package).

> If you want to get a documentation system, well you do, you download
> another .tgz and here you are, you got it.  If things would be 
> packaged in
> rpm/deb, it would be even more trivial - apt get autogsdoc.

Yup.

> > I don't think this would be the case ... for  usability with lF and 
> > Cocoa
> > you would need someone to support it for those systems, and would
> > need to build and install the additions library from gstep-base.
> For usability with lF and Cocoa you should probably use libxml2 
> directly,
> which works almost everywhere.  Opengroupware does a lot of XML 
> portably
> on all platforms by just using libxml2 (Helge correct me if I'm wrong).

Hm, I don't fully understand the question. libFoundation has no XML 
support at all (only required for XML plists according the the 
Foundation spec, right?)
Since we do not use XML plists in OGo, I don't care ;-)

Otherwise we use skyrix-xml which has pluggable XML drivers (SAX 
drivers), pretty much similiar to an EOAdaptor. This can use libxml2 
(for HTML/XML), expat or CFXML on MacOSX, the application itself has no 
dependencies on any specific backend.
IMHO XML really doesn't belong into Foundation (even Java doesn't do 
this ;-).

> > > - independend versioning
> > Am not sure what you mean by this or why it should be considered
> > a good thing.
> It means if you fix a bug in autogsdoc you don't need to make a new
> gnustep-base release.  You just make an autogsdoc release, and users 
> only
> need to download the new autogsdoc, not reinstall the entire 
> gnustep-base.

Exactly. Autogsdoc certainly has little to do with gstep-base. By 
having separate packages for unrelated functionality, you get more 
stable bindings.

> > The purpose of autogsdoc is for the developer (not the end user, but 
> > someone who fixes bugs in and contributes to the the GNUstep 
> > codebase) to be able to generate and view new documentation as s/he 
> > makes changes to the source, so that the barrier to having 
> > corrected/up-to-date documentation is minimised.

I agree. Thats why it shouldn't be part of gstep-base. Why bother 
endusers with that? We are supposed to have more endusers than 
developers, right?

> > Making them download a separate package is putting a barrier back up.
> How big is that barrier though ?

Little, as developers can deal with CVS while endusers cannot deal with 
complexity.
(BTW: with endusers I also mean developers just using gstep-base).

> But for everyone else, it reduces download times, it reduces 
> compilation
> times, it reduces package sizes, it reduces the number of things which
> might go wrong during compilation.  It also enriches gnustep's list of
> packages with an exciting documentation framework, which would 
> otherwise
> slip unnoticed as part of the basic foundation library.

Hurray! ;-)

regards,
  Helge
--
OpenGroupware.org       - http://www.opengroupware.org/