lkml.org 
[lkml]   [1999]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] kernel API documentation system
Jes Sorensen wrote:
>
> >>>>> "Ed" == Ed Grimm <tgape@bigfoot.com> writes:
>
> Ed> On 26 Sep 1999, Jes Sorensen wrote:
> >> Putting auto generated documents in the same directory as the
> >> static ones is a bad idea imho. It makes it hard for people to keep
> >> track of what can be deleted and what cannot.
>
> Ed> Wouldn't the fact that 'make clean' removes it be good enough?
> Ed> How about adding a Documentation/Makefile, which also has a make
> Ed> clean to get rid of them?
>
> This could work, but it is less clear and if you run around trying to
> extract documentation from every C file in the kernel, which I asume
> is the idea, then the Makefile doesn't know what documentation to
> delete and what not to.
>
> I am not against putting auto extractable documentation in the code,
> but I think it would be safer to put the output in a seperate
> directory and not mix it with static files.

Currently the system only generates one huge, whopping kernel-api.html
file. So it's really a non-issue (make clean takes care of it, as noted
above).

But I agree with you -- kernel-doc.pl currently outputs man pages. And
I think it would be handy to generate man pages for kernel API
functions. (my patch only requires a little Makefile scripting in order
to do that)

So, there should definitely be a "Documentation/man" directory or
similar, which is treated just like the current "linux/modules"
directory is now.

Jeff




--
Custom driver development | Never worry about theory as long
Open source programming | as the machinery does what it's
| supposed to do. -- R. A. Heinlein

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.059 / U:0.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site