Fun with banging moon rocks

Monday, February 19, 2018

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)",
    CFLAGS  = "$(CFLAGS) -DNDEBUG -I$(LUA_INCDIR)",
    LDFLAGS = "$(LIBFLAG)",
    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://github.com/spc476/CBOR.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.

The Boston Diaries

Monday, February 19, 2018

Fun with banging moon rocks

Obligatory Picture

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous