I’ve just pushed v1.0.0 of Cproj up to Github. Usage is very simple: source
cproj.sh (I have a line in my
.bashrc to do that when my shell starts up), then type
cproj <projname>. Cproj creates a
<projname> directory and populates it with a ready-to-build project skeleton including source and header files, Makefile, and basic test suite using Scuttle. If Scuttle isn’t installed on the system (Cproj checks the default installation location
/usr/local), Cproj attempts to download it from the main Github repository.
You can immediately
cd <projname>; make to build the project and unit tests and run the test harness.
Next I’ll start a real project. Or maybe I’ll just discover another bit of tooling that needs revision.
A couple of weeks ago, when I got started on what became Scuttle, I mentioned that the reason I wanted a simple but adequately featureful plain-C unit testing framework was that I was frustrated with the limitations of the more ad-hoc solution I’d built into my old
cproj() shell script. It creates an even simpler test facility, but it was too simple.
Now that Scuttle v1.0.0 is done and published, I want to revisit Cproj. I haven’t touched this script in years, and I think there’s a lot of room to clean it up and make it more useful — and update it to use Scuttle as the testing framework it builds into the project skeletons it generates!
Much like Scuttle, the animating philosophy of Cproj is that it should be as self-contained as possible: the script contains its templates for the files it generates as here-documents, and runs pattern substitutions on them to produce the right output. The first time it’s run, the old Cproj actually writes out those templates to
/etc/skel/proj/ (if run as root) or to
$HOME/.skel/proj/, and on subsequent uses reads them from disk instead. I’m no longer sure there’s much value in doing that, so I’ll probably remove that functionality, and just use the here-docs directly every time, like Scuttle does.
After I finish fixing up Cproj, I should be ready to use my revised tooling to start a, you know, real project. Or maybe I’ll just discover another bit of tooling that needs revision.