[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] doxygen.config upgrade; man pages
From: |
Joerg Wunsch |
Subject: |
Re: [avr-libc-dev] doxygen.config upgrade; man pages |
Date: |
Wed, 14 Aug 2002 18:03:21 +0200 |
User-agent: |
Mutt/1.2.5i |
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/