Category: Quill Tcl/Tk Build System

Quill v0.4.0

For those who are interested, I released v0.4.0 of Quill this morning. You can find the release notes at the link.

Quill Notes: Cross-Platform Builds

For Quill 0.2.0 I made Quill a standalone executable (i.e., a starpack) instead of a starkit, so that it would be independent of the Tcl shell being used by the developer. However, I want to deliver Quill for Windows, Linux, and OSX, and I only have an OSX machine, so I added to Quill the ability to do cross-platform builds.

And I bungled it.

The TclDevKit application “tclapp” has the ability to do cross-platform builds, i.e., to build a Windows starpack on OSX. Given a Windows basekit, it will even go out and pull in any required binary packages from teapot.activestate.com. Very nice.

Now, Quill supports building starkits and starpacks; in Quill 0.1.0, these were reflected in the project file like this:

    app mykit -apptype kit
    app mypack -apptype exe

In order to do cross-platform builds in 0.2.0, I just extended this. To build on Linux, Windows, and OSX, enter this!

    app mypack -apptype {linux windows osx}

Then, ‘kite build’ will always build the starpack for each of the listed platforms.

This is bad on several levels.

First, there’s no way to build just for the current platform. This is annoying at best; and if the current platform isn’t one of the three, it’s a real problem.

Second, there are multiple flavors of each of those operating systems, e.g, 32-bit vs. 64-bit Windows.

Here’s a better approach.

First, the “-apptype” option in the project file goes back to two values: “kit” and “exe”.

Second, the “kite build” command always builds “exe” apps for the current platform, whatever it is.

A new “kite build all” command will build everything for the current platform: run tests, format documentation, build library .zip files and executables, and build distribution .zip files.

For projects with an app with “-apptype exe”, a “dist” name can include “%platform” to include the current platform in the name of the distribution .zip file.

So, to build the distribution .zip for this platform (OSX):

   kite build all

Then to build the application and distribution .zip for a specific platform:

   kite build app -platform platform

And there we go.

Quill Notes: Fixing up the Teapot Configuration on Linux

You can find Quill at the tcl-quill GitHub page.

Yesterday, with help from my friend Ted Brunzie I got Ubuntu Linux (64-bit “Trusty Tahr”) running in a virtual machine on my iMac. That means I can actually do Quill testing on 64-bit Linux, which is outstanding.

So far I’ve discovered the following things:

quill teapot create‘ and ‘quill teapot link‘ don’t work right. This isn’t Quill’s fault precisely. Given a typical installation of ActiveTcl on Linux, certain files go in disk partitions owned by “root”. Quill can’t touch these without superuser privileges, which means that certain commands need to be run using ‘sudo‘.

The problem is that the platform’s security policy affects how ‘sudo‘ behaves. On some Linux boxes I’ve used, the command ‘sudo quill teacup link‘ works just fine. On others, Quill can’t see the user’s PATH (which it needs to find the ‘teacup‘ executable) and so it fails. On some of these, if you do ‘sudo -E quill teacup link‘ to preserve the environment, everything works fine.

And as I’ve just discovered, on others even the “-E” flag doesn’t help.

I’ve got a scheme for how to handle that; more on it later.

64-bit vs. 32-bit matters. The ‘quill build‘ command doesn’t make any distinction between 32-bit and 64-bit Linux, except when building a Linux executable on some other platform; and then it assumes you want 32-bit. But this Ubuntu installation is 64-bit; and it doesn’t include all the libraries needed for 32-bit TCL/TK GUI applications. Thus, you might well want to build both 32-bit and 64-bit Linux executables, and the platform you’re actually on matters in ways that hadn’t occurred to me. I’ll be looking into fixing that as well.

WordPress Themes