CASA Build and Package 'blog

Disclaimers...

As far as web-logs go, this one is best read when you desire sleep but find it elusive… actually, it's not so much a 'blog, anyway… but nonetheless, enjoy!

This digression is based upon build and packaging experience acquired in an on-again/off-again fashion since 1990. It was a painful odyssey that involved stops at CMake, DMake, BSD-make, GNUMake, qmake, makemake, rpmbuild, makedep, fastdep, ant, autoconf, tar, portage, yum, MacPorts, and Larry Wall's Configure. Of all of these, Larry Wall's Configure was the only one that had any character.

Any opinions that haven't been removed belong solely the author.

The AIPS++ way…

In the beginning when Geoff created AIPS++ (more recently known as CASA), one of the first requirements was a build system. The system that was developed was finely tuned and crafted. It was very efficient at compiling the system but its configuration was complicated. The build mechanics were written in GNUmake makefiles, and it was configured by setting up files know as makedefs. These files were simply basic GNUmakefiles which set up the pertinent variables needed to build AIPS++. It had the advantage that once configured the build was flawless, expedient, and very repeatable. However, as more developer and adventurous users showed up, it became clear that the initial setup of the makedefs was a hurdle. Undaunted, we carried on with this build system for a very long time, and by and large, for those who stuck around long enough, it worked very well. It carried the project from C++'s pre-template days, through the instantiate yer own template period, and right up to the templates finally work period… we've recently entered the templates are powerful period. It was a rough journey but the basic gmake system carried the project.

Toward the beginning, AIPS++ adopted a distributed scripting language called Glish. To the user, Glish looked a lot like the S language (and in some places Icon), but to the developer working on Glish it looked like Penn Station at rush hour. Glish came with it's own build system. It was a simple, direct system. Unlike the AIPS++ build system which was designed to be general and expandable, Glish's build system was simple and direct. It relied on autoconf to carry much of the load; based upon the environment, autoconf would spit out makefile tailored to the capabilities provided by the OS.

In practice, neither of these systems completely handled the myriad of dependencies that compiling C or C++ involves. Handling the link-time dependencies was completely straightforward, but handling the source code dependencies (from #include) was much, much harder. The kids at home should be forgiven if they are surprised that something so fundamental to reliable building or C applications could be difficult and go largely ignored for a very long time, but it is so. Each #include amounts to a N-ary tree of dependencies. Collating and representing all of these, often redundant graphs is challenging. Besides, developers have the option of rebuilding everything even if it is very time consuming… they'll do it… after they've tried everything else!

It is against this backdrop that a combination of envy of packages which needed only ./configure; make (which Glish had but AIPS++ did not), and frustration at subtle problem, discovered belatedly to be the result of unaccounted for dependencies got the better of the project and we embarked to find a new build system. Now admittedly the unhanded dependencies are very infrequent, but none the less... at times, they could present as almost inscrutable bugs. At any rate, we're off to see The Wizard…

-- DarrellSchiebel - 2014-03-27