It makes more sense for the C documentation of structs to
have the type come first, then the struct member name,
because it reads more like actual C code that way.
Got makedoc.bat to generate compatible documentation with
Linux makedoc script. Started to document all the stuff
developers have to install to work on this project.
I don't want to mix performance information with results.
If I need performance information later, I can do it through
a side channel. Renamed SearchErr to SearchError, to be consistent
with the other functions that generate error structs.
It turns out it simplifies things to merge all the doxygen xml
files into a single all.xml file, then process that. That way
I can find all the struct definitions too.
I looked at moxygen, but it is too C++ centric.
My documentation needs are very simple: I want functions and structs,
and very little else. I want the output to look nice on GitHub.
I don't know if this is going to do what I want, but I'm
hoping I can customize the Markdown output generated by moxygen
to be useful for a simple C library like this. It appears to be
customized for a class-oriented C++ program.
Certain macros and typedefs were ending up in Doxygen output
that have no reason to be documented for outside users.
Mostly I used Doxygen conditionals to hide them.
In a couple of cases I had some internal functions that needed
to be declared static so Doxygen hides them.
Added DoxygenLayout.xml, but not using it yet.
Still trying to figure out how to make Markdown output
that doesn't look terrible. Not sure I can get Moxygen
to do what I want. I may have to create my own simple(?) tool.
The version of doxygen supported in Travis CI appears to be
too old to work with moxygen. This is just not worth the hassle.
I will generate documentation locally, and I will document to
any prospective contributors how to do so also.
