robotlocomotion/cmake

some useful shared cmake utilities

cmake's Issues

MEX_LDFLAGS required on ubuntu + matlab 2014a

drake002.csail.mit.edu is running Matlab 2014a on ubuntu. Commit adcd005 broke the drake build by removing MEX_LDFLAGS from the compile line for mex executables. Restoring that variable fixes the build.

This commit does not break the build for my other ubuntu system, running 2013b.

VERBOSE=1 output:

[...]

Scanning dependencies of target drake_debug_mex
make[3]: Leaving directory `/home/drake/drake-distro/drake/pod-build'
/usr/bin/make -f util/CMakeFiles/drake_debug_mex.dir/build.make util/CMakeFiles/drake_debug_mex.dir/build
make[3]: Entering directory `/home/drake/drake-distro/drake/pod-build'
/usr/bin/cmake -E cmake_progress_report /home/drake/drake-distro/drake/pod-build/CMakeFiles 37
[ 48%] Building CXX object util/CMakeFiles/drake_debug_mex.dir/drakeDebugMex.cpp.o

cd /home/drake/drake-distro/drake/pod-build/util && /usr/bin/c++    -Wreturn-type -Wuninitialized -Wunused-variable -std=c++0x -O3 -DNDEBUG -I/home/drake/drake-distro/drake/pod-build/include -I/home/drake/drake-distro/build/include -I/home/drake/drake-distro/drake/pod-build/lcmgen -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/home/drake/drake-distro/build/include/eigen3 -I/usr/local/MATLAB/R2014a/extern/include -I/usr/local/MATLAB/R2014a/simulink/include    -o CMakeFiles/drake_debug_mex.dir/drakeDebugMex.cpp.o -c /home/drake/drake-distro/drake/util/drakeDebugMex.cpp
Linking CXX executable ../bin/drake_debug_mex
cd /home/drake/drake-distro/drake/pod-build/util && /usr/bin/cmake -E cmake_link_script CMakeFiles/drake_debug_mex.dir/link.txt --verbose=1
/usr/bin/c++    -Wreturn-type -Wuninitialized -Wunused-variable -std=c++0x -O3 -DNDEBUG    CMakeFiles/drake_debug_mex.dir/drakeDebugMex.cpp.o  -o ../bin/drake_debug_mex -rdynamic -L/home/drake/drake-distro/drake/pod-build/lib -L/home/drake/drake-distro/build/lib ../lib/libexelast.a -L"/usr/local/MATLAB/R2014a/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -ldl -Wl,-rpath,/home/drake/drake-distro/drake/pod-build/lib:/home/drake/drake-distro/build/lib 
/usr/bin/ld: warning: libmwresource_core.so, needed by /usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libmwi18n.so, needed by /usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libut.so, needed by /usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libmwfl.so, needed by /usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libmwMATLAB_res.so, needed by /usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so, not found (try using -rpath or -rpath-link)


[...]


/usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so: undefined reference to `MATLAB::catenate::emptyArrayColumnsDimensionMismatch::emptyArrayColumnsDimensionMismatch()'
/usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so: undefined reference to `fl::except::IUserException::ToUstringImpl() const'
/usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so: undefined reference to `MATLAB::legacy_two_part::badformat_mx::badformat_mx()'
/usr/local/MATLAB/R2014a/bin/glnxa64/libmat.so: undefined reference to `H5Tget_member_type'
/usr/local/MATLAB/R2014a/bin/glnxa64/libmat.so: undefined reference to `H5P_CLS_FILE_CREATE_g'
/usr/local/MATLAB/R2014a/bin/glnxa64/libmat.so: undefined reference to `H5T_NATIVE_SHORT_g'
/usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so: undefined reference to `resource_core::BaseMsgID::getName() const'
/usr/local/MATLAB/R2014a/bin/glnxa64/libmx.so: undefined reference to `MATLAB::legacy_two_part::subsassignnumelmismatch::subsassignnumelmismatch()'


[...]

Multiple matlab pods collections on the same machine will conflict

I recently switched my version of IRIS to use the matlab_pods.cmake functions. Unfortunately, calling pods_configure_matlab_paths() in the IRIS build process breaks my drake-distro installation. My setup is something like this:

--- ~
    |--- iris-distro
    |--- drake-distro

so I have ~/iris-distro/build/matlab and ~/drake-distro/build/matlab on my Matlab path. Unfortunately, this doesn't work, because Drake internally uses pods_get_base_path() and similar functions, which it ends up picking up from IRIS instead. This results in weird errors like this:

>> addpath_drake
Warning: Invalid file or directory '/Users/rdeits/iris-distro/build/share/java/drake.jar'.

(it's looking for drake.jar inside IRIS because the IRIS copy of pods_get_base_path() is found first).

Obviously, I could fix this particular problem by putting Drake first on the matlab path, but that will just cause other problems later on.

There are a few things we could consider doing to fix this:

1. Rename pods_get_base_path() and similar functions to include the name of the project (like pods_get_drake_base_path(). This would solve the immediate problem, but would cause other, even more obscure, problems if you were to try to maintain two versions of drake on the same machine.
2. Use environment variables to control the matlab path, the same way we do with PATH, PYTHONPATH, LD_LIBRARY_PATH, etc. In this scenario, the pods_setup_all.sh function would activate the relevant matlab paths at the same time as it sets up all the other environment variables. On mac and linux, we can just set the MATLABPATH environment variable, but on Windows it looks like we'd have to write this functionality ourselves.
3. Move the pods_get_base_path() functions into the source matlab folder, rather than installing them, so that they're only accessible after calling addpath_foo() and thus won't conflict. Of course, once you've called addpath_foo and addpath_bar then whether you get foo's copy of pods_get_base_path() or bar's copy is anybody's guess.

I personally think that #2 is a nice solution, but we'd also need to combine it with #1 to avoid namespace conflicts. The workflow would be:

• build drake
• don't add anything to the matlab saved path
• instead, when you want to use a particular drake distro, just source the pods_setup_all.sh script in that distro before starting matlab. If you only have one distro, then you can just put that source command in your .bashrc.

This provide a consistent workflow no matter whether you're using the Drake c++ libraries, python tools, or matlab scripts.

Of course, this also has a number of disadvantages:

• it doesn't work at all on windows unless we write all the code ourselves
• it doesn't work if you launch matlab by double-clicking on the application instead of launching it from a terminal
• it requires our users to change their workflow

I think that the minimal change that would solve the immediate problem is to just do #1. Users with multiple drake installations will still have to manually manage their path within matlab, but they're presumably used to that.

Pods should parse pre-processor definitions from pkg-config files

Currently, pods_use_pkg_config_packages calls pkg-config with the --cflags-only-I option and uses the result to populate the list of include directories. However, this means that pre-processor definitions that packages place in their pkg-config file (e.g for Bullet compiled with double-precision: -DBT_USE_DOUBLE_PRECISION) are ignored.

Most recent commit throwing error, Apr 26 commit fine

Not an issue really, just a note for next time /drake points to a fresher /cmake commit.

With the most recent commit in RobotLocomotion/cmake, I got a "Could not find MEX_CC using mex -v" error for which a fix was documented at at RobotLocomotion/drake#53

Running just the following commands in /drake fixed this issue

git submodule init
git submodule sync
git submodule update

To verify that it was just the cmake update that was the difference, I did make clean, went back into cmake, git pulled in cmake, tried to compile again and got the same "Could not find MEX_CC using mex -v" error. I then made clean and redid the commands above in /drake and was able to make fine.

I'm also on Yosemite like in the issue linked above, and perhaps the fix for that got lost between the April 26 stable commit and the most recent one?

matlab r2012a (at least) on windows writes a specific pdf filename via the /PDB flag into LD_DEBUGFLAGS

i need to remove that, since i'm effectively telling every mex file to use dummy.pdb
it hasn't reared it's head for me, since i rarely build in debug mode. (I just noticed it in passing)

pods_use_pkg_config_packages searches repeatedly for the same package

On windows machines, this can be very slow (especially on machines with mounted network drives, it seems). As described in http://www.cmake.org/Wiki/CMake_Performance_Tips , we could avoid that by using the cache. I've updated pods_find_pkg_config_packages, and should really update this method, too.

matlab_clean is not terminating child matlab process when it receives it's SIGKILL from a ctest timeout.

at least on windows. this leads to a ridiculuous number of effectively dead matlab processes.

Cannot find mex with correct MATLAB_ROOT provided

I have Matlab R2016a and its symbolic links installed in /usr/local/MATLAB/R2016a, /usr/local/bin respectively:

$ which mex
/usr/local/bin/mex
$ file /usr/local/bin/mex
/usr/local/bin/mex: symbolic link to `/usr/local/MATLAB/R2016a/bin/mex'

Although the variable MATLAB_ROOT in mex.cmke is correctly set to /usr/local/MATLAB/R2016a, the search for the mex executable fails in mex.cmake at:
find_program(mex NAMES mex mex.bat HINTS ${MATLAB_ROOT}/bin NO_DEFAULT_PATH)

I either need to manually provide the path without MATLAB_ROOT:
find_program(mex NAMES mex mex.bat HINTS /usr/local/MATLAB/R2016a/bin NO_DEFAULT_PATH)
or allow to search in default paths:
find_program(mex NAMES mex mex.bat HINTS ${MATLAB_ROOT}/bin)
to successfully determine the full path to the mex executable.

I have tested this behaviour with CMake 2.8, 3.5, 3.7.

Add better entry points in mex.cmake for executables and shared libraries

Using add_mex for all three is not good for readability

(moved this over from issue 20 in drake)