The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Monday, February 19, 2018

Fun with banging moon rocks

Back in Debtember, I was notified of a potential problem with one of my Lua modules, speficically, the LuaRocks specfile of said module—it failed to compile properly on Mac OS-X.

I finally got around to it and fixed the issue, and while I was doing that, I figured I might as well fix some of the other Lua modules I have.

You can always tell when I do this because the version numbers accumulate in a rapid succession. My CBOR Lua module went from version 1.2.4 to 1.2.11 in the span of an hour or so. And it's all due to the picky little details.

As I mentioned a few months ago, I pull the version directly from git. But I also have to define the version in the Makefile in case someone downloads the code instead of cloning the repository. But there have been times when I updated the GitHub repository without updating the Makefile, or forgot to properly rename the LuaRocks specfile (probably as a sanity check, the filename needs to include the version number which is also specified inside the file). To handle those cases, I added a script to git to check for such things before pushing the update to GitHub.

So it should be easy, right?

Not quite.

One issue I forgot to check in the script was to ensure the LuaRocks specfile was syntactically correct. So there goes one version.

The Lua module is written with C99. So I specified c99 as the compiler in the LuaRocks specfile. Only the default options LuaRocks uses breaks on Mac OS-X with c99 as the compiler. The why is simple—Mac OS-X uses clang, which supports different options than GCC. But LuaRocks defaults to using GCC when compiling on Mac OS-X. That's fine, because there's a GCC wrapper on Mac OS-X that translates the options for GCC to clang, but only if the compiler you use is GCC. On Mac OS-X, c99 defaults to clang so of course it fails because clang receives options for GCC.

I can use the default compiler that LuaRocks defines on Mac OS-X and it compiles fine. But not on Linux, where GCC defaults to “not C99.” I finally figured out the magical incantation to fix that:

build =
  platforms =
    windows =
      type    = "builtin",
      modules = 
        ['org.conman.cbor_c'] = 
          sources = { 'cbor_c.c', 'dnf.c' },
          defines = { 'VERSION="' .. source.tag .. '"' },

        ['org.conman.cbor']     = 'cbor.lua',
        ['org.conman.cbor_s']   = 'cbor_s.lua',
        ['org.conman.cbormisc'] = 'cbormisc.lua',
  type = "make",
  build_variables =
    CC      = "$(CC)",
    LUA     = "$(LUA)",
  install_variables =
    LIBDIR = "$(LIBDIR)",
    LUADIR = "$(LUADIR)",
    LUA    = "$(LUA)",
  platforms =
    linux   = { build_variables = { CC = "gcc -std=c99" } },
    solaris = { build_varaibles = { CC = "c99"          } },

And it worked fine. But it burned through some additional versions as I worked out the details. And then I found an issue—if you look closely, you'll notice that I have the patforms stanza twice. That means the second stanza replaces the first stanza and thus, I lost the Microsoft Windows compiling instructions.

So yet another version goes by as I merge the two platforms stanzas into a single block.

And then I forgot to update the version number in the LuaRocks specfile. It had the right name, but the wrong internal version.

So there's another version and an update the the checking script.

By now, you might be wondering why I don't bother testing this before updating the version number. And it's simple—I can't! The LuaRocks specfile contains this bit:

package = "org.conman.cbor"
version = "1.2.11-1"

source =
  url = "git://",
  tag = version:match "[^-]+"

To test it, LuaRocks will download the code from GitHub using the given tag value, which is based off the version number. But if I haven't checked in the code for that tag, LuaRocks will fail. So I have to check in the code with the proper tag before I can test the LuaRocks file.

Yes, I could do the code updates and afterwards fix the LuaRocks specfile, but the script that's run prior to pushing changes checks to see if the latest version is a “good version,” like 1.2.10. It will reject a version like 1.2.10-1-g5b75b4f (which is git's way of saying “one commit past the previous tagged version”). I added that check to ensure LuaRocks would get the proper version of everything—I would only push when I had everything ready for a new version.

Ah—unintended consequences.

We'll see if the next update goes smoother. One of these days I'll get this right.

Obligatory Picture

[It's the most wonderful time of the year!]

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2019 by Sean Conner. All Rights Reserved.