Re: Making autogsdoc a separate package

[Nicola Pero]

> >>> I'd like to propose to make autogsdoc a separate package from
> >>> gnustep-base.
> >
> > Excellent idea, IMHO! Only pros:
> > - code size of gstep-base is reduced
> 
> Net code size increased (as Adam pointed out ... more to maintain).

I see gnustep-base as the basic foundation library for Objective-C, very
much like libc is for C.

When you download libc you don't get an entire header parser /
documentation framework included, do you ?  Which makes sense - you're
getting the libc shared library, the basic library letting you build and
run C programs, you're not asking for a documentation system.

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).  You should not get an entire
documentation system - you should just get the basic foundation library to
build and run Objective-C tools and programs.

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.

Anyway, that's how I see it, I understand you see it differently.

 
> > - more easy to use as a separate tool with lF&Cocoa
> 
> 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).  


> > - 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.


> > Well, an end-user certainly doesn't generate the documentation himself 
> > (at least he shouldn't be required to do so). Also documentation 
> > itself should be a separate package, IMHO (eg I almost never install 
> > documentation packages, but rather prefer to look at web docs).
> 
> 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.
> 
> Making them download a separate package is putting a barrier back up.

How big is that barrier though ?

Installing autogsdoc as a separate package is certainly no challenge for
someone enough knowledgeable to actually fix bugs and contribute to the
gnustep core codebase.  It would even be kept on the same CVS - you just
need to checkout another directory, then make/make install in it, and here
you are, the documentation tool is setup.

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.