Re: [avr-libc-dev] doxygen.config upgrade; man pages

[Joerg Wunsch]

As Theodore A. Roth wrote:

> Feel free to do that. Hmmm... I wonder if you could flag things to be
> included or excluded from the man page output?

I haven't seen anything yet.

> I seem to remember seeing
> something like conditionals in the doxy statements.

There are \htmlonly and \latexonly commands, but as i understand it,
they include the following text verbatim.  Also, there are no
conditional operations on them (like !\latexonly && !\htmlonly :).
But wait... there was something about preprocessing.  Maybe that could
be tweaked for the purpose.

> Well, in my experience, having man pages in a non-standard place
> poses two problems:

>   - users will not even know about it or see it if they don't know about
>     the $MANPATH env var.

Hmm, there could be a meta-manpage just describing the overall
purpose, and giving a pointer to the new man pages.

>   - `man -k` will be incomplete (at least on the redhat) unless the admin
>     adds that path to whatever dirs makewhatis looks at.

/etc/manpath.conf could be modified by the package installation
procedure.

OTOH, this is the only practical way to offer the manlinks feature,
since otherwise, the AVR man pages would name-clash with too many
system man pages (in particular in packaging systems that use
$PREFIX=/usr).  Think of all the standard C library functions...

> :) I don't like the version number in the docs installation directory.

> I don't think it hurts any thing by having it. It does let you know,
> though, if the docs you are looking at are stale.

I don't think so.  They only let you know how old they are, but in
order to justify whether they are stale, you'd need to know there's a
new version available already. ;-)

> Also, there's no other place I know off where you can get the
> version number of the libc which is installed on the system (This
> could be done in a header or something though).

Well, then place a VERSION file directly into that directory. :)

> Thus, there's no strong argument for changing it (except that you
> don't like it ;-) and a few weak arguments for keeping it as is. I'd
> say leave it for now.

I'd at least like to get it ./configure-able.  Having the date in
there is more maintenance headaches for me as the FreeBSD package
maintainer...
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/