Failing to build Target / does not exist

[osrf-migration]

Original report (archived issue) by Tarun Uday (Bitbucket: tarun.uday).

---

Hi,

I have a issue similar to #40 (#40):

I'm running Ubuntu Bionic (18.04), ROS Melodic, Gazebo 9, CMake (3.10.x). Msot of my debug workflow has been centered on the Issue#40 comments

#!bash
CMake Error:
  Error evaluating generator expression:

    $<TARGET_PROPERTY:protobuf::libprotobuf,INTERFACE_INCLUDE_DIRECTORIES>

  Target "protobuf::libprotobuf" not found.


CMake Error:
  Error evaluating generator expression:

    $<TARGET_PROPERTY:ignition-math4::ignition-math4,INTERFACE_INCLUDE_DIRECTORIES>

  Target "ignition-math4::ignition-math4" not found.

locate FindUUID gives me 2 instances:

#!bash
/opt/ros/melodic/share/cmake_modules/cmake/Modules/FindUUID.cmake
/usr/lib/x86_64-linux-gnu/cmake/ignition-cmake0/cmake0/FindUUID.cmake

Adding a message after ign_pkg_check_modules(UUID uuid) in the second one, shows the message.
But, if I rename the second one to FindIgnUUID.cmake, and catkin_make, I get the error:

#!bash
CMake Error at /usr/share/cmake-3.10/Modules/CMakeFindDependencyMacro.cmake:48 (find_package):
  By not providing "FindUUID.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "UUID", but
  CMake did not find one.

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

    UUIDConfig.cmake
    uuid-config.cmake

  Add the installation prefix of "UUID" to CMAKE_PREFIX_PATH or set
  "UUID_DIR" to a directory containing one of the above files.  If "UUID"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/ignition-transport4/ignition-transport4-config.cmake:109 (find_dependency)
  /usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake:191 (find_package)
  original/vgazebo_plugins/CMakeLists.txt:35 (find_package)

I noticed that the error was coming from /usr/lib/x86_64-linux-gnu/cmake/ignition-common1/ignition-common1-targets.cmake at line 65 that says:

#!bash
set_target_properties(ignition-common1::ignition-common1 PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/ignition/common1;\$<TARGET_PROPERTY:ignition-math4::ignition-math4,INTERFACE_INCLUDE_DIRECTORIES>;\$<TARGET_PROPERTY:UUID::UUID,INTERFACE_INCLUDE_DIRECTORIES>; [...] "
  INTERFACE_LINK_LIBRARIES "[...]"
)

I rearranged it to see if that was the only issue:

#!bash
set_target_properties(ignition-common1::ignition-common1 PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/ignition/common1;\$<TARGET_PROPERTY:UUID::UUID,INTERFACE_INCLUDE_DIRECTORIES>; [...] \$<TARGET_PROPERTY:ignition-math4::ignition-math4,INTERFACE_INCLUDE_DIRECTORIES> "
  INTERFACE_LINK_LIBRARIES "[...]"
)

and now I get:

#!bash
CMake Error:
  Error evaluating generator expression:

    $<TARGET_PROPERTY:protobuf::libprotobuf,INTERFACE_INCLUDE_DIRECTORIES>

  Target "protobuf::libprotobuf" not found.


CMake Error:
  Error evaluating generator expression:

    $<TARGET_PROPERTY:UUID::UUID,INTERFACE_INCLUDE_DIRECTORIES>

  Target "UUID::UUID" not found.

So rearranging that list of INTERFACE_INCLUDE_DIRECTORIES gets me the same error but with whatever is the first TARGET_PROPERTY. At this point, I try @mxgrey 's workaround, and add ign_import_target(UUID) to my package's CMakeLists.txt, which gives me the error:

#!bash
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/ignition-cmake0/cmake0/IgnImportTarget.cmake:88 (add_library):
  add_library cannot create imported target "UUID::UUID" because another
    target with the same name already exists.
    Call Stack (most recent call first):
      original/vgazebo_plugins/CMakeLists.txt:36 (ign_import_target)

As mentioned in #40, removing ${GAZEBO_LIBRARIES} from target_link_libraries solves the problem but obviously isn't a workaround. I notice that this person had the exact issue, and that was over a year ago, before the Issue#40 thread existed.

Any directions or tips would be helpful.

[osrf-migration]

Original comment by Tarun Uday (Bitbucket: tarun.uday).

---

• Edited issue description

[osrf-migration]

Original comment by Tarun Uday (Bitbucket: tarun.uday).

---

• Edited issue description

[osrf-migration]

Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

---

If this is the first error you're encountering:

CMake Error:
  Error evaluating generator expression:

    $<TARGET_PROPERTY:protobuf::libprotobuf,INTERFACE_INCLUDE_DIRECTORIES>

  Target "protobuf::libprotobuf" not found.


CMake Error:
  Error evaluating generator expression:

    $<TARGET_PROPERTY:ignition-math4::ignition-math4,INTERFACE_INCLUDE_DIRECTORIES>

  Target "ignition-math4::ignition-math4" not found.

then I don't expect it's related to the FindUUID.cmake confusion.of issue #40.

Your error makes it sound as though your gazebo-config.cmake file is not calling find_package(igniition-transport4) and find_package(ignition-math4). However, your other errors do show ignition-transport4-config.cmake being called, so something very odd is happening.

Could you try reverting all your installed packages back to normal, completely deleting your build directory, running catkin_make again, and then put all of the build output in a gist https://gist.github.com/ and share the gist with us?

[osrf-migration]

Original comment by Tarun Uday (Bitbucket: tarun.uday).

---

Here you go: https://gist.github.com/tarunuday/11184f9b598d1e619fc76f9719b5f70f

[osrf-migration]

Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

---

Thanks, this makes me further suspect that your issue is unrelated to the UUID::UUID issue, although it's still hard for me identify what might be wrong.

Would you be able to share your CMakeLists.txt file? I'm concerned that maybe the wrong version of Gazebo is being searched for by cmake.

Also could you share the contents of the file /usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake? And can you tell me if you've ever installed a version of Gazebo to your system from the source code?

I recommend putting the file contents in gists to help keep this thread readable. Thanks for your help in debugging this!

[osrf-migration]

Original comment by Tarun Uday (Bitbucket: tarun.uday).

---

Sure, would love to solve this.

I had a ton of packages that I removed so that I can point the conflict out and recreate the error. I'm making minor edits to the original issue to represent the names of the packages as it is now (changing gazebo_plugins to vgazebo_plugins)

The vgazebo_plugins package is a package with a couple of executables, and depends on gazebo_plugins which is installed from apt.

Here is the vgazebo_plugins/CMakeLists.txt file

Here is the gazebo-config.cmake file

Not sure if you'd like this but here is what I get if I do sudo apt policy *azebo*. I have no gazebo packages in my ros workspace source. I had installed gazebo_ros_pkgs from source after this error started appearing in an attempt to fix it, but it did nothing, and I removed it.

[osrf-migration]

Original comment by Tarun Uday (Bitbucket: tarun.uday).

---

• Edited issue description

[osrf-migration]

Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

---

I don't expect this to particularly help, but one tweak I recommend making to your CMakeLists.txt is to change this line to:

find_package(gazebo 9 REQUIRED)

to make sure that you have the desired version of Gazebo installed. I don't think this will affect anything in your case, but it's always better to be safe than confused.

I'm really struggling to think of a reason that this issue would be happening. I'm going to make some unconventional suggestions to help with debugging. Could you put the following lines into your CMakeLists.txt following line 34:

find_package(ignition-math4 REQUIRED)
find_package(ignition-cmake0 REQUIRED)
find_package(IgnProtobuf REQUIRED)

One thing I can say for sure is that I can make a dummy project using the exact CMakeLists.txt file that you provided, and run catkin_make_isolated and it works with no problem at all. I just created empty dummy files/directories for:

include/
src/Teleporter.cpp
src/vgazebo_ros_tricycle_drive.cpp

And then I made some minimally functional files for

package.xml
msg/Teleporter.msg

I'm using Ubuntu Bionic (18.04), ROS Melodic, Gazebo 9, and CMake 3.10.2. Here's the output from my catkin_make_isolated call for reference. I have to assume there's some kind of issue with the way packages are installed on your end, but even if that's the case I have a hard time comprehending how you'd get the particular set of issues that you're experiencing.

[osrf-migration]

Original comment by Tarun Uday (Bitbucket: tarun.uday).

---

The CMakeLists modifications didn't help.

I've reduced the entire workspace to the bare minimum and uploaded it. Here's my setup:

#!bash
mkdir -p /other/dev/ #This is where we clone the workspace
sudo chmod 2775 /other #set permissions (in case this a problem?)
cd /other/dev/
git clone https://github.com/tarunuday/ws_error
cd ws_error
catkin_make -j1 #Run catkin_make on single thread to see build output chronologically

My generated build output: https://gist.github.com/tarunuday/b3b7ffe43bc1e1519e0a87bea95604e6

Things that do avoid the CMake error

1. remove either of the two packages.

2. catkin_make_isolated; essentially the same as removing either of the packages

3. Removing {GAZEBO_LIBRARIES} from src/vgazebo_plugins/CMakeLists.txt:29

[osrf-migration]

Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

---

Okay, the fact that there are two packages involved makes the issue much much more clear. I didn't realize that the issue was emanating from a package that transitively depends on Gazebo rather than a package that depends on Gazebo directly. Now I understand how the issue could be happening.

I think the source of the issue may be the use of old-fashioned catkin_make combined with this check which opts to not re-load the Gazebo config when it's already been loaded.

The problem is that the first time the Gazebo config-file gets loaded is when it's requested by vgazebo_plugins, and it works perfectly fine there. When action_layer subsequently tries to load the Gazebo config, the Gazebo config file believes it's already been loaded so it doesn't bother redoing everything. But the previous load of the config-file was in a different cmake scope, so the declarations of the imported targets aren't available in the new scope of action_layer.

This is why catkin_make_isolated is recommended instead of catkin_make. Personally, I strongly prefer catkin build over any of the other catkin options. You can install catkin build using $ sudo apt install python-catkin-tools.

[osrf-migration]

Original comment by Tarun Uday (Bitbucket: tarun.uday).

---

Fascinating. But isn't gazebo_plugin simply a secondary dependency of action_layer? Will any package that has nodes that calls gazebo and has gazebo as a secondary dependency have this issue?

Since vgazebo_plugins library only had 2 nodes, I moved them to action_layer and made action_layer directly dependent on gazebo_plugins, removing the intermediary package vgazebo_plugins completely. Interestingly, #40 UUID Error came up - I solved that by putting in ign_import_target(UUID) as recommended in that thread. What's more interesting now is that there are packages that are dependent on action_layer (another_layer -> action_layer -> gazebo_plugins, similar to ... action_layer -> vgazebo_plugins -> gazebo_plugins), but since they don't have any nodes/libraries that call gazebo, they don't give me any errors.

Longer term, catkin build seems to be the way to go. Thanks a ton for your help.

[osrf-migration]

Original comment by Tarun Uday (Bitbucket: tarun.uday).

---

• changed state from "new" to "resolved"

[osrf-migration]

Original comment by Tarun Uday (Bitbucket: tarun.uday).

---

• changed state from "resolved" to "open"

[osrf-migration]

Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

---

Will any package that has nodes that calls gazebo and has gazebo as a secondary dependency have this issue?

Only if you use the old-fashioned catkin_make. There are good reasons that catkin_make_isolated and catkin build are the recommended ways to build workspaces these days.

but since they don't have any nodes/libraries that call gazebo, they don't give me any errors.

The error happened because vgazebo_plugins had a public dependency on targets like protobuf::libprotobuf. In cmake, the public dependencies of library L will get inherited by any downstream library D that calls target_link_libraries(D [PUBLIC|PRIVATE} L).

That means library D wanted to link against the target protobuf::libprotobuf. You got an error because the CMakeLists.txt for library D couldn't find a target named protobuf::libprotobuf. If each package were configured independently, then that error wouldn't happen. The error occurs because catkin_make unceremoniously smashes all the CMakeLists.txt of your workspace into one project configuration. The Gazebo config file is designed to only be invoked once per project configuration because otherwise there's a risk that it could get redundantly called numerous times, resulting in a needlessly slow configuration time. However, cmake targets don't have global scope (global imported targets aren't supported by cmake until version 3.11). Since the Gazebo config first gets loaded in the scope of library L's CMakeLists.txt, its imported targets won't be visible in the scope of library D's CMakeLists.txt because those scopes are parallel to each other. Nevertheless, the Gazebo config file won't reload in the scope of library D because it has already been loaded once for this project.

Building the packages in isolated configurations is the safest and most sensible thing to do in all cases, not just in this particular case.

[osrf-migration]

Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

---

• changed state from "open" to "resolved"

Users should build their ROS workspaces using catkin_make_isolated or catkin build, not using catkin_make.