Creating a C Documentation Generator - Part 6
Welcome to last post in the series in which we design and implement
- a source code documentation tool for the C programming language.
In this post we are going to release the 0.1 version of
cdoc, WOOOO! Over the past five posts we have gone from an empty C file to a (mostly) functional documentation generator (prototype). We will now perform the magical incantations to bump our version from 0.0 to 0.1 and unleash
cdocupon the world!
Bump the Version and Add a Release Tag
Fortunately, the only code change needed for the 0.1 release of
cdoc is an
update to the
VERSION macro that we defined in part 1.
VERSION macro is defined as:
#define VERSION "0.0"
With a quick change to:
#define VERSION "0.1"
cdoc now reports that it is version 0.1:
$ make clean cdoc
rm -f cdoc cdoc.o
c99 -O0 -g -c cdoc.c
c99 -o cdoc cdoc.o -O0 -g
$ ./cdoc --version
The source code with this change can be found here. To make things all official we will add a git tag pointing to this commit:
$ git tag v0.1
$ git push origin v0.1
And with that, version 0.1 of
cdoc is released.
Release 0.1 marks the end of this series, but not the end of
The goal of this series was to build a documentation generator from scratch, and
after 5+ posts we have done just that1.
There is a lot of work that needs to be done to bring
cdoc out of an
alpha-quality state, and I hope to accomplish that work over the coming months
Here is a small sampling of things on the TODO list:
- Remove all global state from
- Set up unit & integration tests for functions in
- Add doc-comments for all functions & data structures in
- It's kinda funny how this whole series was about writing a documentation
generator, but I never thought to actually document the documentation
- It's kinda funny how this whole series was about writing a documentation generator, but I never thought to actually document the documentation gerator
- Add a README and manual
- I can't tell people to RTFM if I never WTFM
- I should probably wait until I test
cdocon some projects and make updates to the documentation language before spending a ton of time on a manual
- Fix source parsing so that it correctly handles comments
- Add some way to document the members of a
sections inside the data structure definition
- Right now all members have to be documented in the doc-comment above the data structure which leads to poor information locality
- Clean up the overall code quality of the project
Thank you so much for joining me on this journey. I hope you enjoyed reading this series of posts as much as I enjoyed writing them. If you have any questions, comments, or concerns please feel free to reach out to me by email.
Cheers and stay hydrated!
1. Plus each of these posts take a weirdly long time to put together and I have other important stuff I need to do.