On Tue, Feb 15, 2011 at 01:04:27PM -0500, Gaetan Nadon wrote: > On Tue, 2011-02-15 at 07:52 +1000, Peter Hutterer wrote: > > > On Mon, Feb 14, 2011 at 02:12:15PM -0600, Chris Bagwell wrote: > > > On Sun, Feb 13, 2011 at 10:28 PM, Peter Hutterer > > > <peter.hutte...@who-t.net> wrote: > > > > Hi all, > > > > > > > > Just letting you know that after 0.10.11 I'll probably put a strict > > > > requirement on doxygen usage on every new function. > > I am out of context here, just picking up on the word "doxygen". > > Consider using this macro from util-macros, so as not to reinvent the > (configuration) wheel. > > > # XORG_WITH_DOXYGEN([MIN-VERSION], [DEFAULT]) > # -------------------------------- > # Minimum version: 1.5.0 > # Minimum version for optional DEFAULT argument: 1.11.0 > # > # Documentation tools are not always available on all platforms and > sometimes > # not at the appropriate level. This macro enables a module to test > for the > # presence of the tool and obtain it's path in separate variables. > Coupled with > # the --with-doxygen option, it allows maximum flexibilty in making > decisions > # as whether or not to use the doxygen package. When DEFAULT is not > specified, > # --with-doxygen assumes 'auto'. > # > # Interface to module: > # HAVE_DOXYGEN: used in makefiles to conditionally generate > documentation > # DOXYGEN: returns the path of the doxygen program found > # returns the path set by the user in the environment > # --with-doxygen: 'yes' user instructs the module to use doxygen > # 'no' user instructs the module not to use doxygen > # > # If the user sets the value of DOXYGEN, AC_PATH_PROG skips testing > the path. > # > > Recommending: > XORG_WITH_DOXYGEN(1.6.1)
sweet, thanks. fwiw, I hadn't planned to actually require doxygen for the build, merely that the comments are present. but with the above - hey, why not ;) Cheers, Peter > > > > > > No issues with me. I've not used documenting tools to date but its > > > readily available on my system. For libraries, I've always wanted to > > > explore it to auto generate the external API docs... but I guess that > > > doesn't apply here. > > > > we can still generate the API docs, they're just a bit pointless since > > no-one interfaces with the driver :) > > which is also why I'm advocating documenting the code, not the header files > > because that is was people are looking at. > > > > > I'm sure we will struggle at first to find that comfortable level of > > > not having to document min() functions... but thats life. > > > > > (withholding comment on your color scheme. :-) ) > > > > it's beautiful :) > > (and the default, I'm too lazy to search for a different one) > > > > Cheers, > > Peter > > > > ------------------------------------------------------------------------------ > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > > Pinpoint memory and threading errors before they happen. > > Find and fix more than 250 security defects in the development cycle. > > Locate bottlenecks in serial and parallel code that limit performance. > > http://p.sf.net/sfu/intel-dev2devfeb > > _______________________________________________ > > Linuxwacom-devel mailing list > > Linuxwacom-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
