[Fwd: AutoGen & libopts]

[Bruce Korb]

using GMail, this bounced:

Hi Kevin Fenzi, Ralf Corsepius, et al.,

Some history and clarifications:

http://www.redhat.com/archives/fedora-extras-list/2006-December/msg00490.html
> I can't find this situation to be satisfactory and actually think this
> situation is messed up. But, AFAICT, nobody but autogen actually uses
> libopts, so this isn't much of a problem.

There are actually tens of projects that I personally know about that
use libopts.  None are widely distributed.  All of them redistribute
libopts.  That is why I separated libopts from the un-disentangleable
(is that a word?) autogen distribution.  The NTP project, however, has
a version in the pipeline that uses libopts, so there will be one you've
likely heard of soon.  Though, again, it redistributes libopts.

So, the "libopts" package is for one purpose:  to allow developers of
other projects to require that it be installed on production machines
in order to keep sources out of their own package.

"libopts" by itself is pretty useless.  The interface is sufficiently
complicated that hand coding to it is infeasible.  That is why a
definition language gets translated into C code and data structures.
That is what the autoopts templates do, with the help of autogen.
In turn, autogen uses these templates and the library to process its
options.  Separating them is more pain than it is worth.

C.F.:  Yeah, what a mess. ;(

I'd suggest either one big ball of wax (as I have done it for years),
or use the partitioning done by Debian:

libopts -- runtime library
libopts-dev -- headers, man pages, etc. for compiling a project with
               autoopts generated source
autogen -- various binaries, templates and docs for generating source.
See: http://packages.debian.org/unstable/devel/autogen

Matt Kraai is the maintainer: kraai in the debian organization.
He might give you some hints, Paul, about his reasoning.

Hope that makes the "mess" a little more understandable.

Regards, Bruce