On Tue, 05 Jun 2012 10:41:45 +0200, Diego Biurrun <[email protected]> wrote: > On Mon, Jun 04, 2012 at 12:04:50AM +0200, Anton Khirnov wrote: > > On Sun, 03 Jun 2012 23:56:29 +0200, Diego Biurrun <[email protected]> wrote: > > > On Sun, Jun 03, 2012 at 11:43:23PM +0200, Anton Khirnov wrote: > > > > On Sun, 03 Jun 2012 17:53:22 +0200, Diego Biurrun <[email protected]> > > > > wrote: > > > > > They are not really header files, so treating them as templates is > > > > > more > > > > > consistent. This also fixes generation of Doxygen documentation, > > > > > which > > > > > got confused by #including files within function declarations. > > > > > > > > side note: I'd really appreciate it if you could integrate doxy > > > > generation into the build system > > > > so only doxy for the installed headers is generated. > > > > > > I don't think that is a good idea. While much of our doxy should not > > > really be doxy, restricting doxy generation to installed headers is > > > not the right solution. > > > > Care to elaborate? > > > > I think it would be an improvement. Our users are only interested in the > > public API, having file and symbol lists filled with internal stuff just > > makes it harder for them to find what they need. > > Libav devs AFAIK don't read doxy for internal stuff either (or does > > anyone?). > > Doxygen is not a tool intended for external API documentation;
Oh? Why is that? Seems to me we use it for exactly this purpose. > it does > not make a difference where the API is used. If you want to separate > internal and external API more clearly, group them appropriately in > Doxygen. There is no reason not to use Doxygen for internal APIs. Sorry, what? Nobody uses generated doxy for internal APIs and they clutter the output. IMO that is a very good reason not to use doxygen for internal APIs. If you want to go through all our files and setup the groups properly, go ahead. But I think it's a lot of pointless work, so generating the doxy only for installed headers is a much better solution. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
