As of this writing, the version of Csound available in the Ubuntu repositories is 4.23. But you know: I wanted 5.

Fortunately, I've been compiling programs since the 1980's (TRS-80 Alcor Pascal, anyone?) I've even compiled my own Linux system from source code (Linux from Scratch, LFS id 13279).

That's about where my expertise ends. You write it, I build it and run into the bugs -- and complain when they hit my windshield ;-)

So anyway, from long experience, I've developed a sort of procedure. See, when you custom install packages, a lot of times, the options repeat in later releases. You really don't want to have to slog through the documentation all over again to figure out each option you set the last time you built the program.

My primary programming language nowadays is Python (I wrote a module called PcSets -- which I'd be updating now, if I hadn't got started with Csound!) So I was overjoyed to find Csound was using scons. All you have to do is run into one messy Makefile to appreciate the difference.

So here we go. My ad hoc procedure for compiling Csound 5.08 on Ubuntu, with some advice along the way.

1. The Usual

Download the source, untar it in some safe user-owned directory, and cd inside the archive when it opens. If something goes wrong, just back out, erase the whole thing, and start over from this point by reopening the archive. Unlike eggs, a bad compile can be 'unbroken'.

2. Get Developed

OK. You should be following closely the directions in the Building Csound section of the manual. What we will be doing is adding, not subtracting or replacing.

The manual suggests a number of packages and libraries. Generally, just having a package on your system is not enough. If the guide suggests 'libsndfile', the Ubuntu 'libsndfile1' package won't do it. For each package, you need the development files as well. These contain all the headers the compiler will need for linking to those libraries.

Therefore, for every package you want to play a part in your Csound build, you need the '-dev' version as well. In the case above, you will need both 'libsndfile1' and 'libsndfile1-dev'.

3. Better Living through Logging

You can get a good idea of how well you've met your requirements by running 'scons -h', as suggested in the manual. However, here's where we make a left turn. Ever notice how all that info scrolls by incredibly fast? Frequently, during and after a build, you want to refer back to that scrolled info, but can't -- the program's compiling, or the terminal's long since been shut down.

Solve it through logging. Every time I generate a page full of options, I log the output using something like the following:


scons -h 2>&1 | tee ../options.txt


Now when I open options.txt with a text file editor (usually Kate, because it's fast, clean, and light), I have all the possibilities layed out before me. This is going to be important, because the next step is

4. Faster Optionlists, Cut! Paste!

One of the aggravating problems in the shell is the unintentional typo that has hilarious consequences (when you talk about it months later). It's not that funny when it happens. I stopped this a long time ago by writing out the exact command I was going to use in advance, and by doing as little typing as was necessary.

Remember 'options.txt'? Toward the end, the options look sort of like this excerpt:


...
pythonVersion: Set to the Python version to be used.
default: 2.5
actual: 2.5

buildCsound5GUI: Build FLTK GUI frontend (requires FLTK 1.1.7 or later).
default: 0
actual: 0
...


Now, this list goes on, and on, and on. If you think you're going to memorize a list of 20 or so CamelCASE OpTionS with the correct values -- well, good luck. Typing this in by hand is the quick route to a headache. Here's a test -- don't look back at the list above -- and no fair answering if you're a Csound developer -- was that a.) buildCsound5gui, b.) buildCSound5GUI, or c.) buildCsoundGUI? And was it set or not set?

The better way is to avoid the issue. Open a new text file. We will call it options.sh, just in case you want to run it like a shell script. Write down everything, and every option you want. Do NOT rely on the old Mark I eyeball for this -- for each option, highlight the word in the text file, and copy it into the options.sh file using the middle mouse button. That way, if something goes wrong, it's at least not your typo.

By the time I was finished going through each option, and writing my options.sh file, it looked like this:


scons \
useDouble=1 \
buildCsoundAC=1 \
buildCsound5GUI=1 \
useOSC=1 \
buildPythonOpcodes=1 \
buildRelease=1 \
buildStkOpcodes=1 \
buildVirtual=1 \
buildInterfaces=1 \
buildCSEditor=1 \
buildNewParser=1 \
buildLoris=0


12 options, correctly named, correctly set. Ready to go! (Your options may be different depending on what you want to build and what you have on your system.)

5. Boo Boos

I meant to build the Loris opcodes. Unfortunately, on my system, when I unpacked the Loris code as directed, and set buildLoris=1, the compile failed, saying it couldn't find 'Opcodes/Loris/lorisgens5.C'. My best guess is that somewhere in the code, scons is being told to look for a file that's no longer necessary or no longer included. I presume it will be fixed in a later update. In the meantime, I have, what, 1403 opcodes to play with? I'll get by.

I also meant to try running the gcc 4.0 optimizations, but again, I had a phantom file problem. These things happen. I just applied a heavy dose of forgeddaboutit and moved on. After all, my goal was to make music, not improve Csound's performance speed by 5%.

6. Install!

Using the command line above (which I copied and pasted into the shell window), Csound5 compiled with no problems on my system. I've been running 5 since 5.06.

And maybe by the time we reach 5.23, I'll be good at it! ;-)

7. The Step Beyond the Last Step

So you ran ./install.py, and Csound is now on your system. A lot of people at this point erase their build directory, and send the source code tarball off to an archive somewhere.

All my source code is stored in /usr/local/src, in a separate directory for each complete package. Therefore, anything I needed to compile Csound 5 is in the /usr/local/src/Csound5 directory.

That includes the options files I generated!

That way, I only have to figure this out once every few versions. I look through the Changelog, and if anything that affects the compile options has come up, I will redo the option list. But 'options.txt' and 'options.sh' are stored right along with the source code -- there's never any doubt about "Hmm, did I compile in this or that feature?" I can just open the command file and look.

If you are super paranoid, you can even do the logfile trick during the install. This is how I caught a number of errors during Linux From Scratch -- I could go back into the log of the build and see any errors or accidents.

And no complaining about cluttering up the hard drive with text files. I mean, we generate 10 Mb audio files all the time -- I don't think the hard drive is going to implode because of one more 4.0 K text file. However, it does make organizing the source code into separate folders (by topic) absolutely necessary.

I hope this article was helpful. Failing that, maybe it was odd enough to be amusing ;-)