Per the discussion in #1860, starting at this comment.
As with other optional prerequisites of Drake, we should have the ability to run a build and test while excluding matlab from the picture, even if it happens to be installed on the system.
To @david-german-tri for triage.
I'm unconvinced this is solving a real problem, but if it makes the difference between people installing MATLAB and not I want to fix it regardless.
Some of Drake's external dependencies (notably LCM) run find_program(matlab matlab) in their own CMake files. @jwnimmer-tri, will you be satisfied if Drake itself fails to find MATLAB (as with other optional dependencies), or do you require MATLAB to disappear from the entire transitive closure of the superbuild?
Ideally, I'd like to be able to reproduce all of the #1923 supported Ubuntu configurations locally -- or perhaps more realistically, to at least within the measurement error of CI.
At the moment, drake/drake code has vastly different compile times, test outcomes, and possible failure modes in the with-matlab and without-matlab variants, which is my main interest in this ticket.
TTBOMK, the Ubuntu CI variants of with-matlab and without-matlab don't seem to differ in how LCM behaves (or really anything in the superbuild in general), so I'm fine with leaving LCM's matlab sensing alone. Certainly I'm fine with just adding a matlab knob to drake/drake for now, and getting LCM in a second pass if it ever becomes a problem.
I'll also note that USE_MATLAB seemed to be the consensus on the other thread for the best way to make a build behave as if matlab wasn't installed. If there's some other easier or better way (environment variables, schroot, treating unlicensed matlab as if matlab were missing, ...), I'm game for any recipe that is reliable.
(The background here being that the main users of Drake that I will be supporting will not have matlab installed, so I want to test that configuration primarily -- but I also want to opt-in to matlab in order to run the full CI suite locally when the need arises.)
I'm unconvinced this is solving a real problem ...
For me the problem is that I use Matlab for various things myself so it is always on my machine. But a good part of my job is to get Drake to full functionality without Matlab -- it's going to be hard to claim success with that if I can't turn off Drake's use of Matlab!
OK. It seems to me like the situations in which you'll need to reproduce a no-MATLAB result are rare, and you could accomplish it just by renaming your MATLAB executable temporarily. (Haven't actually tested this yet, so perhaps find_program is much smarter than I'm assuming.)
Regardless, a USE_MATLAB flag for drake itself is pretty straightforward, so I'll go ahead and do that. Thanks for the feedback!
you could accomplish it just by renaming your MATLAB executable temporarily
I renamed the Matlab installation directory and that outsmarted find_program.
a USE_MATLAB flag for drake itself is pretty straightforward
If there is a hard part, it is getting the message down to the externals in the superbuild.
I just ran into this issue when trying to test the conversion to FindMatlab.cmake add_matlab_unit_test. FindMatlab.cmake can find matlab without matlab being in the PATH. This meant that in some cases matlab was found and some cases it was not. This results is crashes and other odd things in the matlab tests.
With a CMake superbuild project, the nice thing is that you can send flags and cache values from the superbuild into the children projects. I would say we should come up with a way of finding/enabling matlab, then push that option equally down to the child projects via -D flags. We could have a USE_MATLAB option in the toplevel superbuild CMakeLists.txt. The default value of that option could be set to ON if matlab is in the PATH. The next step would be passing the use of matlab and its location to all the projects build in the superbuild.
Not to change the subject, but I think the same mechanism enabling / disabling Matlab would be useful for enabling / disabling support for ROS in Drake.
Instead of adding a USE_MATLAB option at the super-build level and inventing a mechanism to pass this option down to child projects using, for example, -D flags, how about simply modify the various CMakeLists.txt to check for an environment variable like DRAKE_DISABLE_MATLAB_SUPPORT that, when set to true, disables Matlab support? If this environment variable is not defined, default to the current behavior which is to include Matlab support if Matlab is found.
I don't like environment variables because they can change. That is what the CMakeCache.txt file is for. You set options for the build and they stay that way until you change them in the CMakeCache.txt file with ccmake or cmake-gui. Environment variables can change, also cmake does not know to look at them each time the build is run, only when cmake is run. So, CMake options are the place for things like this not env vars.
I see. OK thanks for the explanation.
Most helpful comment
For me the problem is that I use Matlab for various things myself so it is always on my machine. But a good part of my job is to get Drake to full functionality without Matlab -- it's going to be hard to claim success with that if I can't turn off Drake's use of Matlab!