This section is meant for people who want to build the Urbi SDK. If you just want to install a pre-built Urbi SDK, see Section 13.
To bootstrap this package from its repository, and then to compile it, the following tools are needed.
At Gostai, you can use the script ‘common/install/install-boost’ to set up Boost as we use it.
$ cd /tmp
$ wget http://pyyaml.org/download/pyyaml/PyYAML-3.09.zip
$ unzip PyYAML-3.09.zip
$ cd pyYAML-3.09
$ python setup.py install
At least on OS X you also need to specify the PYTHONPATH:
We heavily use Git submodules, i.e., we subscribe to other Git repositories, which themselves may depend on other submodules. Unfortunately Git’s support for recursive submodules is not nice. We have scripts in common (named ‘git-my-foo ’, also available as ‘git my-foo ’) that make this easier. Since they call each other, set your PATH to go into common/git.
Run
You should really compile in another directory than the one containing the sources.
See ‘../configure --help’ for detailed information. Unless you want to do funky stuff, you probably need no option.
To use ccache, pass ‘CC=’ccache gcc’ CXX=’ccache g++’’ as arguments to configure:
The builds for windows use our wrappers. These wrappers use a database to store the dependencies (actually, to speed up their computation). We use Perl, and its DBI module. So be sort to have sqlite, and DBI.
It might fail. The most important part is
It might suffice, I don’t know...
We support two builds: using Wine on top of Unix, and using Cygwin on top of Windows.
Both builds use our wrappers around MSVC’s cl.exe and link.exe. It is still unclear whether it was a good or a bad idea, but the wrappers use the same names. Yet libtool will also need to use the genuine link.exe. So to set up Libtool properly, you will need to pass the following as argument to configure:
$ AR=lib.exe \
CC=’ccache cl.exe’ \
CC_FOR_BUILD=gcc \
CXX=’ccache cl.exe’ \
LD=link.exe \
DUMPBIN=’/cygdrive/c/vcxx8/VC/bin/link.exe -dump -symbols’ \
RANLIB=: \
host_alias=mingw32 \
--host=mingw32
where:
Since we are cross-compiling, we also need to specify CC_FOR_BUILD so that config.guess can properly guess the type of the build machine.
We use our cl.exe wrappers, which is something that Libtool cannot know. So we need to tell it that we are on Windows with Cygwin, and pretend we use GCC, so we pretend we run mingw.
The following options have been used with success to compile Urbi SDK with Visual C++ 2005. Adjust to your own case (in particular the location of Boost).
$ ../configure \
-C \
--prefix=/usr/local/gostai \
--enable-compilation-mode=debug \
--enable-shared \
--disable-static \
--enable-dependency-tracking \
--with-boost=/cygdrive/c/gt-win32-2/d/boost_1_39 \
AR=lib.exe \
CC=’ccache cl.exe’ \
CC_FOR_BUILD=gcc \
CXX=’ccache cl.exe’ \
LD=link.exe \
DUMPBIN=’/cygdrive/c/vcxx8/VC/bin/link.exe -dump -symbols’ \
RANLIB=: \
host_alias=mingw32 \
--host=mingw32
Should be straightforward.
Using distcc and ccache is recommended.
There are some special variables in addition to the environment variables documented in the manual.
Skip lines in input that look like shell output. A way to accept *.chk as input.
Display the desugared ASTs instead of the original one.
Ignore failures (such as differences between kernel revision and ‘urbi.u’ revision) during the initialization.
The path to urbi-launch that urbi.exe will exec.
Don’t try to catch SEGVs.
Enable Bison parser traces.
Display stats about execution rounds performed by the kernel.
The location of the libraries to load, without the extension. The LIBname are: LIBJPEG, LIBPLUGIN (libuobject plugin), LIBPORT, LIBREMOTE (libuobject remote), LIBSCHED, LIBSERIALIZE, LIBURBI.
Enable Flex scanner traces.
Force the display the result of the top-level evaluation into the lobby.
There are several test suites that will be run if you run ‘make check’ (‘-j4’ works on most machines). To rerun only the tests that failed, use ‘make recheck’.
The test suites are declared as “lazy”, i.e., unless its dependencies changed, a successful test will be run only once — failing tests do not “cache” their results. Because spelling out the dependencies is painful, we rely on a few timestamps:
Updated when a library is updated (libport, libuobject, etc.).
Updated when an executable is updated (urbi-launch, etc.). Depends on libraries.stamp.
When Urbi sources (‘share/urbi/*.u’) are updated.
Updated when any of the three aforementioned timestamps is.
These timestamps are updated only when make is run in the top-level. Therefore, the following sequence does not work as expected:
$ make check -C tests # All passes.
$ emacs share/urbi/foo.u
$ make check -C tests # All passes again.
because the timestamps were not given a chance to notice that some Urbi source changed, so Make did not notice the tests really needed to be rerun and the tests were not run.
You may either just update the timestamps:
$ make check -C tests # All passes.
$ emacs share/urbi/foo.u
$ make stamps # Update the timestamps.
$ make check -C tests # All passes again.
or completely disable the test suite laziness:
You can run each test suite individually by hand as follows:
Tests libport.
Checks liburbi, and some of the executables we ship. Requires the kernel to be compiled in order to be able to test some of the uobjects.
Tests the kernel and uobjects.
Partial runs can be invoked:
wildcards are supported:
To check remote uobjects tests:
The snippets of code displayed in the documentation are transformed into test files.