Ok, for a variety of reasons I’m attempting a from source build on Mac OS X Snow Leopard, as mostly documented at http://www.ardour.org/building_osx_native?destination=node%2F1266
Yes, I really want to do this, but I have a few specific questions regarding versions, a clarification on buildsystems, and some miscellany. Note that it is not my intention to release any binary builds, just build them for myself (I already did the donation, subscription, and ‘buy Mixbus’ things…); Paul needs to eat, ya’know!
The biggest reason is so that I can customize the code to use more of the TASCAM US-428 capabilities (I want to do things like track selection via the aux buttons, change mappings based on button selections, and in general get the full use of the US-428’s control surface which I don’t think is possible through the stock General MIDI controls). My intent is to release the source contributions back to the project as a ‘US-428/224’ patch of sorts (and I want to use that same thing on Linux, but the US-428 driver on Linux isn’t nearly as full-featured as the OS X one). A more general macro-language to define MMC actions and do logic by MMC is I guess the ultimate goal, then anyone could write a ‘MIDI/MMC’ macro set for any specific surface to gain much use of that surface. Just a thought…
A second reason is to track the 2.0-ongoing branch in the ardour SVN on OS X.
Thirdly, if I’m going to go to the effort of doing OS X at all, I want to DO OS X, not just use it… the Linux geek in me shows through…
In any case, the questions:
1.) What specific versions of the gtk-osx stuff are used for the ‘official’ build? A listing of ~/gtk/source would suffice. Here’s what I have from last night in my ~/gtk/source:
XML-Parser-2.36 XML-Simple-2.18 atk-1.28.0 autoconf-2.63
automake-1.10.1 automake-1.4-p6 automake-1.7.9 automake-1.8.5
automake-1.9.6 cairo-1.8.8 expat-2.0.1 fontconfig-2.7.3
freetype-2.3.11 gettext-0.17 glib-2.22.2 gnome-common-2.28.0
gnome-doc-utils-0.10.13-fake2 gtk±2.18.2 gtk-doc-1.11
ige-mac-integration-0.8.6 intltool-0.40.6 jpeg-7
libpng-1.2.40 libtool-2.2.6 m4-1.4.11 pango-1.24.5
pixman-0.16.0 pkg-config-0.23 pkgs tiff-3.9.1
2.) What specific version of gtk+ is the gtk patch for (I know the specific revision is 20839, but it seems the gtk+ project has changed revision control systems recently, and while I know how to get specific revisions with subversion, git is a whole different story)?
3.) Paul wrote a post for the Imendio developer forum about packaging Ardour, but it’s empty (GTK-OSX isn’t at Imendio anymore, but on sourceforge…). Anyone have an archive of that post?
4.) How in the world is a macports installed scons supposed to work with a GTK-OSX jhbuild-using application when the GTK-OSX developers are adamant about macports/fink not being in $PATH when using jhbuild ( http://sourceforge.net/apps/trac/gtk-osx/wiki/Build which states “If you have MacPorts or Fink installed, be sure to remove their paths from $PATH, $DYLD_LIBRARY_PATH, $PKG_CONFIG_PATH and any build-related environment variables ($CFLAGS, $LDFLAGS, etc.) before you try to run jhbuild. Mixing Fink/MacPorts and GTK-OSX will fail.”)? And since to build Ardour you need the macports scons and the GTK-OSX jhbuild shell both at the same time… I guess just looking for clarification if just making sure the GTK-OSX jhbuild and the necessary bits for GTK-OSX come before the macports stuff in the various PATHs is sufficient to prevent the problems the GTK-OSX people seem to have with macports…
5.) Not a question, but an observation: GTK-OSX at the current (as of last night) build is bundling freetype and fontconfig of appropriate versions when the ‘jhbuild bootstrap && jhbuild build meta-gtk-osx-bootstrap && jhbuild build meta-gtk-osx-core’ sequence completes. Yes, I fixed the 64-bit building issue with the following lines in ~/.jhbuildrc-custom:
32-bit i386 build…
And I setup the PATH properly with a ‘jhwrap’ script that sets up PATH to exclude the macports stuff and add ~/.local/bin to the PATH.
And that’s as far as I got last night in the build; downloaded most of the rest of the stuff, but the gtk patch stymied me since I wasn’t sure if it would even apply to the version I got. I am planning to do more tomorrow night or Saturday, or whenever I get more clues as to how to get revision 20839 of the gtk.patch patched gtk. And I’ll get there, sooner or later, but having this documented I think would be good.
This makes building ardour from source on Linux look like a positive cakewalk, even doing things like packaging a .deb or a .rpm (which I’ve done…) seem trivial (and 2.8.3 backported to Fedora 11 wasn’t trivial when doing it the ‘RPM way’ and rebuilding from source RPM, which I’ve already done…But Paul said as much in the article about the subject!