find_package(drake) doesn't work on ubuntu 16.04

[manuelli]

The spartan repo is using drake as a Cmake external project. Some of our code requires drake. Here is a very simple CMakeLists.txt file from the project

find_package(drake REQUIRED)

add_executable(iiwa_status_to_residual
    run_iiwa_status_to_residual.cc
    kuka_iiwa_status_to_residual.cc
    )

target_link_libraries(iiwa_status_to_residual
    drakeCommon
    drakeLCMUtil
    lcm
    yaml-cpp)

install(TARGETS iiwa_status_to_residual
    RUNTIME DESTINATION bin
    LIBRARY DESTINATION lib
    ARCHIVE DESTINATION lib)

the source code is here. This works fine on my machine running ubuntu 14.04 but doesn't work on the robot-lab computer running the kuka arm which is running 16.06. The error message at compile time is

- Configuring done
CMake Error at src/CMakeLists.txt:3 (add_executable):
  Target "iiwa_status_to_residual" links to target "Eigen3::Eigen" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

CMake Error at src/CMakeLists.txt:3 (add_executable):
  Target "iiwa_status_to_residual" links to target "Eigen3::Eigen" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

CMake Error at src/CMakeLists.txt:3 (add_executable):
  Target "iiwa_status_to_residual" links to target "Eigen3::Eigen" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

CMake Error at src/CMakeLists.txt:3 (add_executable):
  Target "iiwa_status_to_residual" links to target "Eigen3::Eigen" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

CMake Error at src/CMakeLists.txt:3 (add_executable):
  Target "iiwa_status_to_residual" links to target "Eigen3::Eigen" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

CMake Error at src/CMakeLists.txt:3 (add_executable):
  Target "iiwa_status_to_residual" links to target "Eigen3::Eigen" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

CMake Warning (dev) at /home/robot-lab/spartan/build/install/lib/lcm/cmake/lcmUtilities.cmake:358 (add_library):
  Policy CMP0063 is not set: Honor visibility properties for all target
  types.  Run "cmake --help-policy CMP0063" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  Target "lcmtypes_cpf-lcm" of type "STATIC_LIBRARY" has the following
  visibility properties set for C:

It says it can't find any of the targets even though they should be found after calling find_package(drake).

@patmarion

[patmarion]

I'm not positive the issue is strictly affecting ubuntu 16, but that's the only difference I can think of between the machines where it works and where it doesn't. We really want to start using find_package(drake) for our projects, but this is blocking us right now when we develop on ubuntu 16.

The find_package(drage) is also broken on mac, because it fails to find vtk (installed in homebrew) when searching for drakes dependencies. Resolving the issue on mac is a lower priority than ubuntu 16.

[patmarion]

btw, this is the error printed on mac, see below.

I think it would be helpful to also print some status messages in the drake-config.cmake file so that it's obvious in the output that these dependency look ups are happening as a result of find_package(drake).

this is blocking us on two platform now. let me know if there's anything i can do to help debug. i hope it's easy to replicate this issue using the simple example code posted in the first comment.

-- Found GTest: /Users/pat/source/spartan/build/install/lib/libgtest.dylib  
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE  
-- Found Bullet: /Users/pat/source/spartan/build/install/lib/libBulletDynamics.dylib  
-- Found PythonInterp: /usr/local/bin/python (found version "2.7.13") 
-- Found PythonLibs: /usr/local/opt/python/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib
-- Performing Test HAS_CPP14_FLAG
-- Performing Test HAS_CPP14_FLAG - Success
-- Performing Test HAS_CPP11_FLAG
-- Performing Test HAS_CPP11_FLAG - Success
CMake Error at /usr/local/Cellar/cmake/3.7.2/share/cmake/Modules/CMakeFindDependencyMacro.cmake:55 (find_package):
  By not providing "FindVTK.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "VTK", but
  CMake did not find one.

  Could not find a package configuration file provided by "VTK" with any of
  the following names:

    VTKConfig.cmake
    vtk-config.cmake

  Add the installation prefix of "VTK" to CMAKE_PREFIX_PATH or set "VTK_DIR"
  to a directory containing one of the above files.  If "VTK" provides a
  separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  /Users/pat/source/spartan/build/install/lib/drake/cmake/drake-config.cmake:40 (find_dependency)
  CMakeLists.txt:5 (find_package)

[patmarion]

ping @jamiesnape any suggestions?

[jamiesnape]

@mwoehlke-kitware will take a look.

[david-german-tri]

I'm tagging this as high priority, since we want a baseline-working find_package(drake) before the #3129 cutover.

[jamiesnape]

The before and after will not be comparable in any way, though. The only common variable will be drake_FOUND=TRUE.

[mwoehlke-kitware]

I'm having trouble reproducing... there is a problem on my system with find_dependency and /usr/share/cmake/Modules/FindEigen3.cmake (from eigen3-devel-3.2.10-1.fc25.noarch), but I had no problem finding VTK.

How are most of the dependencies found? I take it CMAKE_PREFIX_PATH points to Drake's install prefix? Does <CMAKE_PREFIX_PATH>/lib/vtk-5.10/VTKConfig.cmake exist?

[patmarion]

The find vtk issue is only on mac, where vtk is installed in homebrew so cmake doesn't know how to locate it without a hint.

The other issue is still under investigated, we can reproduce it on some machines but not all machines. It does not seem correlated with whether or not eigen3-dev is system installed. I haven't searched for the root cause. But I think the general issue is that the drake-config.cmake file does not do anything special logic when searching for dependencies, so it can fail under some circumstances.

[mwoehlke-kitware]

The find vtk issue is only on mac, where vtk is installed in homebrew so cmake doesn't know how to locate it without a hint.

Ah... in that case, "set CMAKE_INSTALL_PREFIX appropriately"? (Sigh; CPS specifically addresses this...)

The other issue is still under investigated, we can reproduce it on some machines but not all machines. It does not seem correlated with whether or not eigen3-dev is system installed.

What is Eigen3_DIR and/or EIGEN3_INCLUDE_DIR? Is there any pattern there across "working" and "non-working" systems?

[patmarion]

Perhaps you could setup a test based on the example code provided in the original post, so we can see whether that test passes on drake's ci machines. If it passes there, then I could try running that on the machines where it's currently failing and that could help diagnose the problem. This seems like it would be very productive, to develop a CI test for drake-config.cmake.

[patmarion]

Any updates @mwoehlke-kitware? Having a working drake-config.cmake would benefit so many users.

[jamiesnape]

We are currently finishing up the drake-config.cmake that utilizes the Bazel build.

[patmarion]

This issue is tracking the drake-config.cmake produced by the drake cmake build. Is this issue going to be resolved or wont-fix?

[EricCousineau-TRI]

This may have been resolved in spartan by updating drake. Will see I can test with a simple CMake external as well to see if the current drake revision (cef58fd).

UPATE: This appeared to be some artifact of me sourcing a properly built drake directory, possibly by having the PATH directory updated via spartan/build/setup_environment.sh (from a specific branch of spartan) such that find_package(drake) was able to find it. I did not nail down the specific fix. However, I could not reproduce it off of master of spartan.

[manuelli]

I just wanted to follow up on @patmarion comment on whether the drake-config.cmake produced by the drake cmake build is planning to be fixed? This is a blocking issue for using the kuka arms with drake.

[david-german-tri]

whether the drake-config.cmake produced by the drake cmake build is planning to be fixed?

@manuelli, thanks for the ping. If you're blocked, you are certainly welcome to fix this yourself, but after further discussion I don't see a reason for TRI/Kitware to prioritize it. TRI is committed to the Bazel transition. At this point, we're only investing in CMake development to the extent that it helps that transition.

My thought two weeks ago was that a CMake-based drake-config.cmake, used to build Director in CI, would be a useful baseline for the Bazel-based drake-config.cmake. However, the Kitware experts are telling me I'm wrong about that - the two are different enough that it's faster to head directly for Bazel.

[manuelli]

Ok thanks @david-german-tri. I haven't been following all the Bazel related discussion super closely so maybe some of my questions have been answered elsewhere but here goes.

1. Is supporting downstream projects like spartan that use drake as a CMake external project something that is a priority and will be maintained after the transition to Bazel? Is someone at TRI going to own this (there seem to be a few spartan users at TRI) or is this something we should be in charge of here at RLG?
2. When should we expect the the Bazel build to be fully working and be able to provide drake-config.cmake?

[mwoehlke-kitware]

Is supporting downstream projects like spartan that use drake as a CMake external project something that is a priority and will be maintained after the transition to Bazel?

Yes. Sort-of. The set of available targets is going to change radically, and may change again. (Right now, there is just libdrake.so, which includes at least some bits of third-party libraries e.g. lcm, bullet, fcl... This may change in the future.) So there will be some porting effort required, but in general, we do intend to support CMake consumers of Drake.

See also #5763.

When should we expect the the Bazel build to be fully working and be able to provide drake-config.cmake?

In theory, as of #5763 landing last evening. Attempts to make use of that are encouraged!

[david-german-tri]

@mwoehlke-kitware is correct. To clarify one thing, though - #5763 provides a drake-config.cmake, but the actual headers and object code in the package are currently limited to a few particular Bazel targets. Now that all the infrastructure is up and running, we should be able to add more targets into that list quickly, including whatever spartan needs.

[manuelli]

Ok thanks, a quick list of needed targets for spartan would include at least

• drakeCommon
• drakeLCMUtil
• lcm
• yaml-cpp

This is what is inside target_link_libraries in our CMakeLists.txt. Also we use bot-spy, procman and signal-scope extensively as part of spartan. Are these being build with Bazel? As a follow on is there an easy way to see what parts of drake work with the Bazel build? I assume that the answer will eventually be "everything"

[jamiesnape]

bot-spy yes signal-scope no procman I am not sure, what repo is it in?

[manuelli]

I believe it is part of libbot in drake/externals. Are there timelines for getting all these pieces working with Bazel?

[jwnimmer-tri]

When I last spoke with @sammy-tri on this a month or so ago, we agreed it was reasonable for things like bot-spy or especially bot-procman to be built via Spartan's CMake (super)build directly; there's no reason to indirect them through Drake's Bazel build, since they are just programs.

[manuelli]

Ok so drake is never going to provide these tools when it is used standalone, or are they just not going to be available targets in the drake-config.cmake? I mention this because I consider bot-spy an essential tool when doing anything with lcm?

[mwoehlke-kitware]

FWIW, CMake and CPS do support exporting/importing of executable targets as well as libraries... although in this case, I'd imagine having them available for end users is more interesting.

I'm inclined to agree; if drake-bazel takes over building LCM and libbot for Drake's use, it seems like it ought to be building and packaging their tools as well; otherwise anyone that wants to use them (not just end users, but also downstream projects that need e.g. lcm-gen) has to build those packages separately, in addition to Drake building them. (At which point conflicting libraries also becomes a possibility...)

[patmarion]

So maybe a first proof of concept might look like:

• drake bazel build provides drake libs, headers, and python bindings, and eigen headers (via drake-config.cmake)
• spartan superbuild provides lcm (libs, tools, cmake scripts), libbot (procman), rl/lcmtypes, and signalscope, and of course director and its dependencies

Director (along with pydrake) currently requires:

    libdrakeCollision.so
    libdrakeCommon.so
    libdrakeConvexHull.so
    libdrakeGeometryUtil.so
    libdrakeIKoptions.so
    libdrakeIK.so
    libdrakeJoints.so
    libdrakeMultibodyParsers.so
    libdrakeOptimization.so
    libdrakeRBM.so
    libdrakeRigidBodyConstraint.so
    libdrakeShapes.so

We also use snopt and gurobi.

I understand the bazel build will squash these into a single library. I'm not sure whether the drake bazel build provides lcm tools in a usable form, so I assume spartan will have to build lcm with cmake to get access to that. There is risk in duplicating the lcm library, but perhaps that will be ok.

I am unsure what it looks like when spartan or other downstream users wish to use other external projects that are currently provided by drake superbuild. For example, here are some cmake config files present in the spartan install prefix that were provided by the drake superbuild:

./share/eigen3/cmake/Eigen3Config.cmake
./share/octomap/octomap-config.cmake
./share/cmake/pybind11/pybind11Config.cmake
./lib/bot2-core/cmake/bot2-coreConfig.cmake
./lib/lcm/cmake/lcmConfig.cmake
./lib/cmake/bullet/BulletConfig.cmake
./lib/cmake/gflags/gflags-config.cmake
./lib/cmake/nlopt/NLoptConfig.cmake
./lib/cmake/yaml-cpp/yaml-cpp-config.cmake
./lib/cmake/spdlog/spdlogConfig.cmake
./lib/libf2c/cmake/libf2c-config.cmake
./lib/robotlocomotion-lcmtypes/cmake/robotlocomotion-lcmtypesConfig.cmake
./lib/ccd/ccd-config.cmake
./lib/snopt/cmake/snopt-config.cmake

[jwnimmer-tri]

@patmarion That's very helpful!

I think the next step is first for Drake developers to improve package_drake.sh so it provides those items (and provide them in useful ways), and then second to iterate on what it looks like to switch the build technology over (under the hood) for Spartan, Director, etc.

I'm not 100% sure who owns pushing that forward from the Drake developers side (there are a few moving pieces). We can post back here soon. (Really, it's a separate issue number, I guess?)

I'm not sure whether the drake bazel build provides lcm tools in a usable form, so I assume spartan will have to build lcm with cmake to get access to that. There is risk in duplicating the lcm library, but perhaps that will be ok.

I think load-time compatibility is important, which means either providing Drake's build of the LCM runtime for Spartan to use, or allowing Spartan to provide a build of the LCM runtime for Drake to link against. We can help push on one or the other from the Drake side.

[stonier]

I am unsure what it looks like when spartan or other downstream users wish to use other external projects that are currently provided by drake superbuild. For example, here are some cmake config files present in the spartan install prefix that were provided by the drake superbuild:

If I read this correctly, this is the concern I raised with David the other day. This particular package is nice if you build exclusively on top of Drake, but this looks like it is going to fail hard if user's applications include/link against both drake and other libraries of their own that require system dependencies (which have a different version) of drake's dependencies. e.g. Eigen.

i.e. It is less of a system binary package and more of a virtual environment of its own. Certainly can be a first step to support Director at least, but I imagine a group like the TRI robotics group will need a system binary package to co-exist with all of their other software.

[jwnimmer-tri]

~@soonho-tri~ @stonier That is both off-topic for this issue, and a misinformed understanding both first of the problems at hand and second what the build system roadmap looks like.

[soonho-tri]

@jwnimmer-tri , you meant @stonier , right?

[jamiesnape]

In our rough initial prototype (https://gist.github.com/jamiesnape/3f16b586692c639be286a0faff45afde), we had CMake targets for some of the externals that would be perfectly usable by CMake, but first we are just going to get a build working with a single target that includes all libraries, whether statically linked or otherwise.

[david-german-tri]

As far as I can tell, everyone agrees that

• We will be able to build spartan and other downstream users against a monolithic libdrake.so, so that's a reasonable way to get started.
• It will be possible to split libdrake.so into smaller libraries - both freestanding externals, and smaller pieces of Drake - in the future, as there's a need and as we figure out what exactly those pieces should be.
• It will be possible to improve the drake-targets.cmake, either via CPS or directly, to describe a Drake package that contains several smaller libraries, and the migration burden on downstream projects for those kinds of changes will be small.

So, unless someone disagrees with one of those points, I propose we stop talking about that, and focus instead on the steps needed to switch spartan and director to a Bazel-backed drake-targets.cmake. I think those are:

• [x] Get all the symbols and headers @patmarion and @manuelli requested above into the Drake package (more targets to go into the drake.so).
• [x] Include python bindings in the package or as a separate package, #5843
• [x] Possibly add some executables to the Drake package, as discussed above.
• [x] Integrate package_drake.sh into (at least some variant of) the Drake CMake superbuild.
• [ ] Modify the spartan build system to consume Drake from the package.
• [x] Modify the director build system to consume Drake from the package.

The first three are all unblocked right now and just need someone to work on them.

I've re-re-prioritized this issue as high, since it's now about switching to the Bazel-backed targets - which is an awesome change of course, many thanks @manuelli and @patmarion for the flexibility.

[sammy-tri]

slightly off topic, but since bot-spy came up, it seems worth noting another class of artifacts which are relevant to bot-spy... the java lcmtypes.

drake-distro% PATH=$PATH:`pwd`/build/install/bin bot-spy  
Checking /home/sammy/git/drake-distro/build/install/share/java
   Found /home/sammy/git/drake-distro/build/install/share/java/lcmtypes_bot2-core.jar
   Found /home/sammy/git/drake-distro/build/install/share/java/lcmtypes_bot2-frames.jar
   Found /home/sammy/git/drake-distro/build/install/share/java/lcmtypes_bot2-param.jar
   Found /home/sammy/git/drake-distro/build/install/share/java/lcmtypes_bot2-procman.jar
   Found /home/sammy/git/drake-distro/build/install/share/java/lcmtypes_drake.jar
   Found /home/sammy/git/drake-distro/build/install/share/java/lcmtypes_robotlocomotion.jar

I can't find any equivalent of those files in bazel-*. There are some jar files in bazel-bin/drake/lcmtypes, but it hardly looks like enough for bot-spy to work (for a drake end user or downstream project)

[jwnimmer-tri]

Drake's Bazel build has lcmtypes_bot2-core.jar (though Bazel names it liblcmtypes_bot2-core-java.jar; we should probably rename it to match upstream). Drake could add more jars if that's truly your request -- they should be trivial.

As I said above though, I think Spartan will have an easier time if it builds libbot directly. If you are already in CMake land, you'll probably want the "rooting around for jarfiles in $superbuild_prefix/install" behavior, and you're never going to get that with Bazel -- because with Bazel you have to explicitly list out every piece you want.

[mwoehlke-kitware]

It will be possible to split libdrake.so into smaller libraries - both freestanding externals, and smaller pieces of Drake - in the future, as there's a need and as we figure out what exactly those pieces should be.

I'd sort of like to at least provide LCM as a separate library. Ideally bazel would do this in a way that is compatible with LCM build by CMake, such that users can use either one with no changes on their end. Probably others also, but LCM is especially interesting as far as doing so in a compatible way, since that includes shipping lcmUtilities.cmake as LCM_USE_FILE for anyone that has done find_package(lcm).

It will be possible to improve the drake-targets.cmake, either via CPS or directly, to describe a Drake package that contains several smaller libraries, and the migration burden on downstream projects for those kinds of changes will be small.

My plan is certainly to do so via CPS (implying that cps2cmake will learn to support whatever we need to extract out of the CPS file(s)).

That said, there is a disconnect between what we have now (one CPS that puts everything in the drake "namespace") and what various externals currently provide, e.g. LCM's current exported targets are not "namespaced". We have a choice between adjusting this upstream or adding target alias support to cps2cmake. The latter is less immediate change for consumers, but we may want to pursue both, so that LCM has the option of also eventually shipping CPS. (Note: CPS components are always namespaced; an unqualified name is a package.)

Drake's Bazel build has lcmtypes_bot2-core.jar

Heh. I'd totally forgotten about JAR's; thanks for reminding me. (cps2cmake needs to be taught about those...)

[sammy-tri]

Drake's Bazel build has lcmtypes_bot2-core.jar

Where?

drake-distro% (for i in bazel-bin bazel-drake-distro bazel-genfiles bazel-out bazel-testlogs ; do find $i/  -name lcmtypes_\*; done) | wc -l
0

I'm a bit more concerned about lcmtypes_drake.jar which I can't seem to find either (well, maybe a subset of it in multiple jar files?)

As I said above though, I think Spartan will have an easier time if it builds libbot directly.

There's also bot_core_lcmtypes, robotlocomotion_lcmtypes. Downstream projects can track a list of lcmtypes dependencies and build them again, but it is a list, not a single package.

[jwnimmer-tri]

bazel build @libbot//...
file bazel-bin/external/libbot/liblcmtypes_bot2-core-java.jar

Anyway, sure, things might be missing now. The whole point of this issue is to move forward, test out an integration prototype, and fix / add what's missing.

Also, I am thoroughly uninterested in libraries (of any language) auto-generated from *.lcm files. It is trivial to solve in many ways, and rebuilding them anew takes mere seconds. We will fix it once we have an integration prototype to iterate on.

[manuelli]

Has there been any progress on this issue? As far as I can tell I haven't seen a spartan branch using a drake bazel build with all the targets available. The last movement I saw on this was https://github.com/RobotLocomotion/spartan/commits/bazel-build from May 12. And this was a very limited build, in that it did not build all the pieces of drake needed to run robots.

I find myself wanting to use drake on current projects but am totally blocked by this issue. The only way to currently use drake c++ is from inside drake itself, which is a workflow that doesn't co-exist with trying to stay up to date with the latest drake. Since the bazel build is not yet ready and there hasn't been much movement on this since April 12 is there any chance of just fixing the cmake issue?

I can now confirm that the build error affects ubuntu 14.04 as well, build error message is shown below.

loading initial cache file /home/local/ANT/manlucas/spartan/build/tmp/ContactParticleFilter-cache-Release.cmake
CMake Error at /home/local/ANT/manlucas/tools/cmake-3.5.2-Linux-x86_64/share/cmake-3.5/Modules/CMakeFindDependencyMacro.cmake:65 (find_package):
  By not providing "FindGMock.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "GMock", but
  CMake did not find one.

  Could not find a package configuration file provided by "GMock" with any of
  the following names:

    GMockConfig.cmake
    gmock-config.cmake

  Add the installation prefix of "GMock" to CMAKE_PREFIX_PATH or set
  "GMock_DIR" to a directory containing one of the above files.  If "GMock"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  /home/local/ANT/manlucas/spartan/build/install/lib/drake/cmake/drake-config.cmake:40 (find_dependency)
  src/CMakeLists.txt:1 (find_package)

[jamiesnape]

Follow #3129. When all the boxes in the installation TODO are checked, we will have a working Drake installation package that Director and Spartan can use.

[jwnimmer-tri]

For Spartan, see also WITH_ISSUE_5456_WORKAROUND as in https://github.com/RobotLocomotion/spartan/issues/101#issuecomment-307434772.

[manuelli]

The workaround just doesn't build anything that targets drake c++. I am planning to just write my own FindDrake.cmake similar to what director does to find all the drake targets.

[stonier]

Spartan is using the ExternalProject_add for the foreseeable future (even with the Bazel transition) so is out of scope for this issue. Additionally, the find_package(drake) mechanism is now working successfully (tested on shambhala), so I am going to close this issue. Further refinements of what is actually installed and working can be handled in new issues individual to each use case.