libmonome and serialosc devs: changes to the build system

  • hey homies.
    first off: this post is mostly aimed at the people who are helping out with libmonome and serialosc or who work on their own forks (owen_vallis, kellydunn, rknLA). also this is relevant if you're trying to compile libmonome or serialosc from source.

    since the first public releases of libmonome and serialosc, we've been using a custom, Makefile-based build system I wrote myself. everything worked //okay//, but left a lot to be desired. particularly, we'd see build problems on ubuntu, darwin, windows...not fun.

    long story short, we're not using that anymore. we're moving to [[|waf]], which is a build system written in python. it //does// introduce a build-time dependency on python, but the savings in code (it's about 1/3 as much as the old system) and the gains in build correctness are worth it, in my opinion.

    as of earlier tonight, libmonome is all-waf; the old makefiles have been removed. serialosc is next.

    here's how to build libmonome now:

    > $ cd libmonome
    > $ ./waf configure
    > $ ./waf
    > $ sudo ./waf install

    almost exactly the same syntax as the old build system, but with better internals. you can, of course, pass "--help" to ./waf at any stage to find the options (such as enabling the python bindings in libmonome).

    i'll post a reply when serialosc is moved over too.


  • Your post is timely as I was just about to post a question about the state of

    My setup is as follows:
    * OS X 10.7
    * Xcode 4.3
    * liblo and libconfuse built via homebrew

    I'm trying to build the Python bindings using the "--enable-python" option to ./waf configure

    However, I'm getting the following error:

    ld: warning: ignoring file src/libmonome.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

    To get around this problem, I've put together a custom file to build the python module from monome.pyx and run it as:

    ARCHFLAGS='-arch x86_64' python build_ext --inplace

    This builds fine, and I can import the it generates from the python interpreter. It seems that waf (or the underlying distutils) defaults to 32 bit on OS X, even when the system is 64 bit.

    In any case, I've been able to compile the module, but it's not clear how to use it. I see there is a Monome class that the cython interface defines. But I can't figure out how to instantiate that. I'm trying to do something like:

    m = monome.Monome("osc", 9000)

    but that raises AttributeError's. When I try it as:

    m = monome.Monome("osc", "9000") # with osc server port in quotes

    I get an "IOError: Could not open Monome" despite the fact that serialosc clearly indicates it's listening on that port.Any tips of documentation on how to get started with the Python module?


    p.s. let me add that using the "oscdump" utility that comes with pyliblo indicates that both my monome and serialosc are working OK on my machine...

  • Good to know :) I need to make your suggested update to the chronome proto class, and also update the flipmu website to reflect these changed build instructions.

  • Confirmed that everything is building peachey keen on OSX. I updated my custom homebrew formula to work with the new waf build system, and have encountered no problems

    pmags... you might find it helpful to install libmonome / serialosc via homebrew instead

  • thealphanerd -- good to know there are brew's available, but from glancing at your recipes on github it doesn't look like your brews also build the python bindings. Or am I missing something?


  • @pmags:
    good catch about the arch thing, i had forgotten about that. waf (gcc, actually) defaults to whatever your system arch is (so it was building with "-arch x86_64" for you and I), but the python extension was being built as a fat binary, both i386 and x86_64. i've added a configuration option (--enable-multilib) that will build the whole of libmonome as i386 and x86_64. we need that for the official builds anyway, so that's a good catch.

    if you build with --enable-multilib, though, you'll need to make sure liblo is also built as multilib. i do it like this:

    > $ cd liblo-0.26/
    > $ CFLAGS="-arch i386 -arch x86_64" ./configure --disable-dependency-tracking
    > $ make; sudo make install

    should be peachy after that.

    now, the runtime issue you're seeing is because you're not passing a valid OSC URL into the Monome constructor. check out the examples in the libmonome/examples/python directory for what proper calls look like. here's one for reference:

    > from monome import Monome
    > m = Monome("osc.udp://", "8000")

    where "8080" is the port serialosc says it's running on, "prefix" is the prefix (natch), and "8000" is the port your application listens on. you will need to set that manually for now (though it would be trivial to have that happen on instantiation, i'll check into that) by sending serialosc a "/sys/port i " with oscsend.

  • @visinin

    re: arch issues

    Would it be possible to add a flag to build *only* as x86_64?

    re: Python binding

    Doh! For some reason I totally overlooked the examples directory.

    Now, a new issue...

    When I instantiate the Monome object as you illustrate above I get a TypeError:

    >>> from monome import Monome
    >>> m = Monome("osc.udp://", "8000")
    Traceback (most recent call last):
    File "", line 1, in
    File "monome.pyx", line 260, in monome.Monome.__init__ (monome.c:2342)
    self.devpath = (monome_get_devpath(self.monome)).decode()
    TypeError: Expected str, got unicode

    Clearly there is some str/unicode weirdness going on, but I'm note familiar enough with the code to figure it out.

  • @visinin

    Stupid question, but where is serialosc living now?

    Last commit was 8 months ago but you guys are mentioning recent changes?

    I see AlphaNerds version, what's my best bet for most recent supported source for serialosc?

  • @bar|none:
    this thread is about libmonome so far. there //has// been work done on serialosc, just in a different branch:

    not recommended unless you're handy with gdb. stick with the master branch.

    ugh. i ported the python bindings to python3 and it looks like that broke things for everybody else. what version of python are you using?

  • @visinin

    I get the problem both on 2.7 (on Lion) and 2.6 (on Snow Leopard).

    And yes there was a major change in that in Python 3 strings are unicode by default.

  • @pmags:

    try reverting this commit:

    might work. either way, i'll look into this when i have a sec. nice to see someone actually trying to use the bindings!

  • @visinin

    Reverting those changes, and keeping things as strings works.

    Thanks a lot for your efforts and quick fixes -- I for one am very motivated to use the Python bindings, as I'm more a Python hacker than a max hacker.

    One pleasant surprise -- when playing with the led_intensity attribute through the Python bindings, my May 2010 GS128 actually seems to have 16 levels of brightness ?! I thought these earlier models only had 4 levels -- is that expected?

  • @pmags

    perfect, good to hear. i need to pore through the docs and see if there's a way to make the bindings build for both py2 and py3. i hope so.

    also, w.r.t. LED intensity...monomes have always have 16 levels of //global// LED intensity, but the jan2011 edition also supports 4 levels of //per-LED// intensity.

  • thanks, visinin! i was one of those having trouble on ubuntu.

    built beautifully on lubuntu 12.04. i updated linux setup wiki with the waf stuff for libmonome.

  • pmags... I do not have the brew compiling with the python bindings by default... but that wouldn't be too difficult to add... let me take a peak tomorrow nad see what I can get going

  • hey again, everyone.
    just popping in to say that serialosc has also been moved over to waf. build instructions are the same for libmonome:

    > $ cd serialosc
    > $ ./waf configure
    > $ ./waf
    > $ sudo ./waf install

    there is some trickiness that needs to happen w.r.t. windows builds. this will be written up in a separate thread.

    feels really good to get rid of that old code. oh man.