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)
> >
> > 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
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
