* * * * *

                         Fun with banging moon rocks

Back in Debtember, I was notified [1] of a potential problem with one of my
Lua modules [2], speficically, the LuaRocks specfile [3] 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 (Concise Binary Object Representation)
[4] 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 [5].
But I also have to define the version in the Makefile in case someone
downloads the code [6] 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 [7].

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:

-----[ Lua ]-----
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"          } },
 }
}
-----[ END OF LINE ]-----

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:

-----[ Lua ]-----
package = "org.conman.cbor"
version = "1.2.11-1"

source =
{
 url = "git://github.com/spc476/CBOR.git",
 tag = version:match "[^-]+"
}
-----[ END OF LINE ]-----

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.

[1] https://github.com/luarocks/luarocks/issues/751#issuecomment-352784223
[2] https://github.com/spc476/lua-conmanorg/blob/master/src/iconv.c
[3] https://github.com/luarocks/luarocks/wiki/Rockspec-format
[4] https://github.com/spc476/CBOR
[5] gopher://gopher.conman.org/0Phlog:2017/11/13.2
[6] https://github.com/spc476/CBOR/releases
[7] https://github.com/

Email author at [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.