Skip to content

ChucK Meta Engineering

Spencer Salazar edited this page May 11, 2016 · 3 revisions

ChucK Meta-Engineering

Testing/Continuous Integration

ChucK has a dedicated testing suite under src/test. A test script, test.py, will run each test in sequence with a given ChucK binary. test.py accepts 2 positional arguments, a chuck binary to test (default: system chuck according to the $PATH variable) and a directory in which it will recursively search for tests. E.g., assuming you just compiled chuck in the src/ directory, you could fully test the newly compiled executable with test/test.py ./chuck test/. There is also a makefile rule that does exactly this, so you can do make test to test the latest compile.

Tests themselves are .ck files that are considered to have succeeded if they print "success" : (string) to stderr, i.e. <<< "success" >>>; in ChucK code. Printing anything else instead of or in addition to this will result in test failure. However tests can specify that a different output is used to indicate success by including that output in a text file that has the same filename as the test except with a .txt extension instead of .ck. See for instance 147_spork.ck and the corresponding text file.

At this time tests are organized into 4 groups with a directory for each: 01-Basic (basic language functionality), 02-UGens (test basic code-level functionality of unit generators), 03-Modules (test various non-audio modules), and 04-Stress (test extreme or edge-case inputs).

At this time ChucK only uses black-box testing (ensuring that a given ChucK program produces the expected output), but not unit testing or other forms of code testing. Experimental support for audio output testing has been started.

The full test suite is automatically run on Mac OS X and Linux for every commit using Travis-CI. For more information, see https://travis-ci.org/ccrma/chuck. Testing on Travis-CI seems to constantly cause the osc01.ck test to fail (for reasons unknown). This can be fixed be rerunning the failed test build.

Release Engineering

ChucK is released in the form of source code in addition to installer packages that provide pre-built binaries for some platforms. Installers are provided for Mac OS X (.pkg installer) and Windows (.msi installer). The installer includes the chuck command line program, miniAudicle, ChucK's dedicated integrated development/ on-the-fly programming environment, and a "standard" set of chugins (from https://github.com/ccrma/chugins).

A source release can be produced by running make src-dist in the src/ directory. This produces a .tgz file named chuck-W.X.Y.Z.tgz where "W.X.Y.Z" is the version number specified in the makefile (the CK_VERSION variable). This .tgz contains the ChucK source code, examples, and additional metadata in a standardized format and without any stray git artifacts. This source archive can then be uploaded to the ChucK website (typically under /release/files/ e.g. http://chuck.stanford.edu/release/files/). make src-dist should work on any platform that includes the standard shell/GNU tools e.g. make, cp, tar, and git.

The installer files are built using makefiles that exist in the miniAudicle source repository. There is one folder for Mac and one for Windows.

To create the installer for Mac, assuming you have checked out the miniAudicle source repo and its submodules, go to installer/mac in Terminal. Running make will first build miniAudicle and the chuck and chugin builds under its directory tree (e.g. miniAudicle/src/chuck and miniAudicle/src/chugins). Note that whatever version of chuck the src/chuck submodule points to is what will be packaged in the installer. Running make clean will clean any by-products of building the installer and the installer itself if it exists. make clean-all will not only clean up all of that but also clean any existing builds of miniAudicle and the chuck and chugin builds under its directory tree.