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 paragraph 16.
This section details the dependencies of this package. Some of them are required to bootstrap the package (Section 20.1.1), i.e., to build it from the repository. Others are required to build the package (Section 20.1.2), i.e., to compile it from a tarball, or after a bootstrap. Finally, some are needed to run the test suite (Section 20.1.3).
The reader in a hurry can simply run one of the following commands, depending on her environment.
sudo apt-get install \
aspell aspell-en autoconf automake bc ccache colordiff \
coreutils cvs doxygen flex g++ gettext git-core gnuplot \
graphviz help2man imagemagick libboost-all-dev \
liblinphone-dev make pkg-config python-docutils \
python-yaml python2.6 socat sun-java6-jdk swig tex4ht \
texinfo texlive-base texlive-binaries \
texlive-latex-extra transfig valgrind
sudo port install \
ImageMagick aspell aspell-dict-en autoconf automake bc \
boost ccache colordiff coreutils cvs doxygen flex gcc42 \
gettext git-core gmake gnuplot graphviz help2man libxslt \
linphone pkgconfig py26-docutils py26-yaml python26 \
python_select socat swig swig-java texinfo texlive \
texlive-bin-extra texlive-htmlxml texlive-latex-extra \
transfig valgrind-devel
To bootstrap this package from its repository, and then to compile it, the following tools are needed.
package: autoconf
$ dirlist=$(/usr/local/bin/aclocal --print-ac-dir)/dirlist
$ sudo mkdir -p $(dirname $dirlist)
$ sudo /usr/bin/aclocal --print-ac-dir >>$dirlist
package: automake
package: cvs
package: colordiff
package: git-core
package: gettext
package: coreutils
package: help2man
deb: python2.6
MacPorts: python26 python_select
package: texinfo
$ 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
MacPorts: py26-yaml
deb: python-yaml
On OS X you may also need to specify the PYTHONPATH:
deb: libboost-all-dev
MacPorts: boost
windows: http://www.boostpro.com/download
package: ccache
package: doxygen
package: flex
deb: g++
MacPorts: gcc42
package: gnuplot
wget http://www.graphviz.org/pub/graphviz/stable/windows/graphviz-2.26.msi
PATH=/cygdrive/c/Program\ Files/Graphviz2.26/bin:$PATH
package: graphviz
MacPorts: ImageMagick
deb: imagemagick
deb: sun-java6-jdk
deb: make
MacPorts: gmake
MacPorts: linphone
deb: liblinphone-dev
deb: texlive-base texlive-latex-extra texlive-binaries
MacPorts: texlive texlive-latex-extra texlive-bin-extra
deb: pkg-config
MacPorts: pkgconfig
deb: python-docutils
MacPorts: py26-docutils
package: swig
MacPorts: swig-java
deb: tex4ht
MacPorts: texlive-htmlxml
package: transfig
MacPorts: libxslt
deb: aspell aspell-en
MacPorts: aspell aspell-dict-en
package: bc
package: socat
deb: valgrind
MacPorts: valgrind-devel
Get the open source version tarball from http://www.gostai.com/downloads/urbi/2.x/ and uncompress it. This version is bootstrapped, you can directly proceed to the “Configure” step.
Run
Do not compile where the source files are (the test suite of a sub-component of ours, Libport, is known to fail in that situation). So, compile in another directory than the one containing the sources, for instance as follows.
Also, do not compile in a directory whose name, or the name of some of its ancestor, use “special characters”: stick to plain ASCII. This is a limitation of the Java VM which seems to be unable to traverse properly directories with UTF-8 names when the locale is set to C (Section 17.1.4).
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:
For the records, here are some of the ‘--enable-’/‘--disable-’ specific options.
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…
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 tools (cl.exe, dumpbin.exe, link.exe). It is still unclear whether it was a good or a bad idea, but the wrappers use the same names as the tools themselves. 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=’dumpbin.exe
RANLIB=:
host_alias=mingw32
--host=mingw32
where: ‘cl.exe’, ‘dumpbin.exe’, ‘lib.exe’, and ‘link.exe’ are the wrappers.
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 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 and the ‘vcxx8’ part).
$ ../configure \
-C \
--prefix=/usr/local/gostai \
--enable-compilation-mode=speed \
--enable-shared \
--disable-static \
--enable-dependency-tracking \
--with-boost=/cygdrive/c/gt-win32-2/d/boost_1_40 \
AR=lib.exe \
CC=’ccache cl.exe’ \
CC_FOR_BUILD=gcc \
CXX=’ccache cl.exe’ \
LD=link.exe \
DUMPBIN=dumpbin.exe \
RANLIB=: \
host_alias=mingw32 \
--host=mingw32
Should be straightforward.
Using distcc and ccache is recommended.
Running ‘make install’ works as expected. It is a good idea to check that your installation works properly: run ‘make installcheck’ (see Section 20.9).
If you intend to make a relocatable tree of Urbi SDK (i.e., a self-contained tree that can be moved around), then run ‘make relocatable’ after ‘make install’.
This step requires that you use a DESTDIR (see the Automake documentation for more information). Basically, the sequence of commands should look like:
$ DESTDIR=/tmp/install
$ rm -rf $DESTDIR
$ make install DESTDIR=$DESTDIR
$ make relocatable DESTDIR=$DESTDIR
$ make installcheck DESTDIR=$DESTDIR
You may now move this tree around and expect the executable to work properly.
There are some special variables in addition to the environment variables documented in the manual.
As a safety net, Urbi checks that loaded modules were compiled with exactly the same version of Urbi SDK. Define this variable to skip this check, at your own risks.
Skip lines in input that look like Urbi output. A way to accept test files (‘*.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.
Force the interactive mode, as if ‘--interactive’ was passed.
The path to urbi-launch that urbi.exe will exec.
Don’t try to catch SEGVs.
Enable Bison parser traces.
Display statistics about execution rounds performed by the kernel.
The location of the libraries to load, without the extension. The LIBname are: LIBJPEG4URBI, LIBPLUGIN (libuobject plugin), LIBPORT, LIBREMOTE (libuobject remote), LIBSCHED, LIBSERIALIZE, LIBURBI.
Enable Flex scanner traces.
Forbid binary communications with UObjects.
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’. Some tests have explicit dependencies, and they are not rerun if nothing was changed (unless they had failed the previous time). It is therefore expected that after one (long) run of ‘make check’, the second one will be “instantaneous”: the previous log files are reused.
Note that running ‘make’ in the top-level is needed when you change something deep in the package. If you forget this ‘make’ run, the timestamps on which the test suite depends will not be updated, and therefore the results of the previous state of the package will be used, instead of your fresh changes.
Some tests are extremely “touchy”. Because the test suite exercises Urbi under extreme conditions, some tests may fail not because of a problem in Urbi, but because of non-determinism in the test itself. In this case, another run of ‘make check’ will give an opportunity for the test to pass (remind that the tests that passed will not be run again). Also, using ‘make check -j16’ is a sure means to have the Urbi scheduler behave insufficiently well for the test to pass. Do not send bug reports for such failures.. Before reporting bugs, make sure that the failures remain after a few ‘make check -j1’ invocations.
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.
Partial runs for the doc tests: