multiple CUDD builds on Travis CI

[johnyf]

Both gr1c and dd.cudd (for testing the option of using omega with cudd) build CUDD on Travis CI, which is suboptimal. For now, we can let this be so, but in the future we may want to consider linking to a common library for all tools that use CUDD. Currently, the aforementioned tools support different CUDD versions, so this is not yet possible.

[slivingston]

How difficult is adjusting dd.cudd to find CUDD in a different location?

With gr1c version >= 0.11.0, the installation location of CUDD can be manipulated by changing deps_prefix before building gr1c.

[johnyf]

It is not very difficult to adjust dd.cudd, it can be done by changing CUDD_PATH, which is defined in download.py. One possibility is to add an optional command line argument to setup.py that defines where CUDD is located.

[slivingston]

At the current tip of master branch (7647d64), a built release of gr1c that is statically linked to CUDD is used on Travis CI, thereby avoiding the need of building CUDD for gr1c. However, now the optional dependency Slugs is built using get-slugs.sh, so we have again a second (i.e., repeated) building of CUDD.

[johnyf]

Building or fetching a binary (perhaps as is done for gr1c) for CUDD needs to happen first, because the default solver (e.g., omega) is installed before optional dependencies are tested (also, versions differ until tulip-control/dd#8 is closed). The Makefile of slugs is not parameterized wrt the path of CUDD.

[johnyf]

dd == 0.4.3 has been released. It uses CUDD v3.0.0 and supports passing a path to the CUDD installation, so in principle it should now be possible to build CUDD v3.0.0 once, and reuse that build when building each tool that depends on CUDD.

[slivingston]

I will attempt to create a CI configuration that only builds CUDD once. Stay tuned for the PR!