FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

I've placed the tds.dox configuration file in src/tds/ and commited my
limited changes to mem.c.  I'm thinking of the modules "Memory
Allocation", "Authentication", "Conversion", "Query", and "Results
Processing" as broad groupings to file the functions under.  We can also
do it by filename, and i believe alphabetic....but I'm not quite an expert
in the tool yet.

I think this would be a wonderful tool for dblib/ctlib/ODBC as well but
those are of lesser importance to me since there is at least some existing
documentation.  But after libtds is on it's way let's do it.

Brian

> > From: Brian Bruns [mailto:camber AT ais.org]
> > Sent: September 13, 2002 8:18 AM
> > 
> > The document is generated off of JavaDoc style comments 
> > within the code, 
> > so helpfully this will be a boon to both developers and those 
> > interested in using libtds.  
> 
> Agreed.  I am also helpfully that this will hope the developers.  
> 
> > Let me know what you think before I go too far down this path.
> 
> I have in mind precisely this style and technology for the client libraries.
> I've mentioned it before, and it's never generated much excitement (or even
> comment), so I have a hard time getting charged up about it.  But I have
> this idea that a library should document its functions, even if the
> functions were defined by someone else.  Otherwise, it's like getting a C
> compiler that comes with the advice, "find some documentation for fopen()
> and stuff.  What it says is what we do."  
> 
> Please incorporate the doxygen stuff into the Makefile.am as a "run it if
> installed" target.  One lesson from the 0.60 release is to deal with
> makefile issues, um, early and and often.  
> 
> I got a response to a months-old request for support from the LXR folks on
> sf.  I'm going to give that another go on the FreeTDS tree.  
> 
> Regards, 
> 
> --jkl