Tales from a phasmatodean man

Peter Miller was a senior software developer with over 30 years on embedded systems. He has experience on a variety of platforms and is renowned for his focus on effective software testing practises. He was one of the the original authors of the now universally used gettext internationalization infrastructure. His last project was writing a library to better “explain” error messages coming from the Linux kernel's various system calls.


Twitter @PeterMillerAus

Google Plus +Peter Miller

Email 0x70405E10

RSS Feed /pmiller

Developers are bad for build systems

It has often been observed that developers are the enemy of build systems. It is a rare person who actually knows how they work. (The variety of OSS build system available now fall into two main categories: (1) make, cook, and jam (et al) work backwards from the outputs; and (2) automake, scons, waf (et al) that work forward from the sources. I tend to blend them, myself, as circumstances require.

One method I use to keep developers away from my build systems is to

  1. Ask the version control system for a definitive list of primary source files.
  2. Using heuristics, generate a Makefile or a Makefile.am file (etc).  Non-recursive, of course.
  3. Make sure the (generated) Makefile knows how to update the Makefile.

The great thing with this method is that when users add a new file to a change set (“svn add”, or similar) the next build will automatically notice it, and rewrite the Makefile (or whatever) and then build your new file.  You can approximate this technique using find(1), and filtering out all build products (heuristically).

Now, this isn’t simple, because users also structure source trees in weird and wonderful ways. But you can depend on some things, like a directory called “lib” almost certainly contains source files to be compiled and linked into a library.

Another pattern is to treat every .c or .cpp file in the “src” directory as a command to be compiled and linked, probably to including that common library of functions. (Except when a some of files under “src” should be a common library, and then you have to look in the source files, looking for the main() function, to find programs to build.)  Don’t bike shed the concept, just hack something that works, and then you can improve it later, in light of experience, and possibly some yak shaving much later for entertainment.

My projects tend to be larger than that, and I use a heuristic that every directory that contains main.c or main.cpp (etc) should have all of it source files compiled and linked into the one program, and also to that common library of functions, probably.  If a program has a name starting with “test_” is is built (for use by automated tests) but not installed.

The point is to manipulate the shape of your source directory tree so that a relatively simple program can generate the build system from the definitive list of primary source files.  For example: you can easily see the mapping from the list of primary source files to the Makfile.am contents, it’s almost 1:1.

Now that users don’t need to edit the Makefile, they don’t need to fsck it up, either.

Also, I always build executables into a single directory called “bin”. It makes it very easy to set the PATH when running automated tests.

The Not-So-Gentle Answer: 10. Perceptions of Strength

For many months now, I have been confused when people tell me that I am a strong person. Some people have even described me as the strongest person they know. This is their perception, and I can’t and shouldn’t argue with them. This blog post is the process of me understanding that perception of me by other people. Continue reading

B4 minus 4 days, and counting

I saw the oncologist today. The bone marrow biopsy results are in, and they are good.  By next week I will have an appointment to see the bone marrow transplant team at St Vincents Hospital. Next week’s Bendamustine could be the last one, unless the transplant team want more.

Things get interesting once we start the transplant ball rolling. “Several” weeks of 5-days-a-week chemotherapy to “condition” my bone marrow, 6 weeks in hospital post transplant, 5 months recovery at home… and that’s the best scenario. I wont be out-of-pocket for the transplant, but commuting and accommodation are another thing.

There is a flip side: the transplant team may decide that I’m not a viable transplant candidate, and the recurring abscess will be a factor in that decision.  (Oh, and I’m off IV Ertapenem, and back on orals, which makes me feel just that little bit liberated.)


There are times that I get caught up thinking about my disease and where it is going and what may happen, and I realized something: Don’t wait until you are dead to say it.

So, to my most honest critic, my greatest fan, and my life’s companion: this one is for you MT.

Bette Middler – Wind Beneath My Wings (lyrics)

I would not be the person I am today without these 32 years with you.

new lintian(1) .changes distribution check

I’m writing this up so I can find it again later, it will affect all of my open source projects (and a few closed source ones, too).

As of Ubunutal Quantal, lintian(1) has added a new test to the things it checks for  in the *.changes file.  It now checks that the Distribution: header contains a known distribution name. Continue reading

B3 minus 1 day, and counting

My body has been tolerating the Bendamustine very well.  My third cycle is coming up tomorrow.  My sister is here to act as my allergic-reaction “spotter“.  To everyone who has helped so far, you have my deepest thanks.  The bone marrow biopsy is booked in for 21-Feb, to decide if we (a) keep on with the Bendamustine, or (b) stop, and look for another drug.

“Memory” by Linda Nagata

The first time I read Memory by Linda Nagata I was ambivalent, it had some interesting ideas, but the plot was a bit… odd.  This time around it was a more entertaining read, and it speaks to a theme I’ve been thinking about for a few years now: multi-decade space ship journeys vs software bugs.

Spoiler Alert

Continue reading

Material on this site copyright © 2002-2014 Operational Dynamics Consulting Pty Ltd, unless otherwise noted. All rights reserved. Not for redistribution or attribution without permission in writing. All times UTC

We make this service available to our staff and colleagues in order to promote the discourse of ideas especially as relates to the development of Open Source worldwide. Blog entries on this site, however, are the musings of the authors as individuals and do not represent the views of Operational Dynamics