Hi, On Sun, Jun 3, 2012 at 3:04 PM, Anton Khirnov <[email protected]> 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 >> >> Planned, let's see if I can find some time soon. >> >> > 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?). > > Therefore there is no reason to generate doxy for anything other than > installed headers.
This is a great point. I don't mind having separate doxy for uninstalled private implementation stuff, if people like that, but it should be strictly separate from what we show to our library users. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
