Original report (archived issue) by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Checked the Q&A board for common solutions: http://answers.gazebosim.org
  • Checked that your issue isn't already filed.
  • Checked that there is not already an Ignition package that provides the described functionality: https://ignitionrobotics.org/libs

Description

If tinyxml2 is a required package for two other packages, in this case ignition-common3::graphics and DART::dart-utils, depending on the order of calls to ign_find_package, tinyxml2 is reported to be not found. This a strange failure because CMake reports that it found tinyxml2 but then subsequently reports that it's missing TINYXML2_INCLUDE_DIRS.

Steps to Reproduce

Here are two CMakeLists.txt files that demonstrate the problem

Failing example:

#!cmake

cmake_minimum_required(VERSION 3.5.1 FATAL_ERROR)
project(test-tinyxml2 VERSION 1.0.0)
find_package(ignition-cmake2 REQUIRED)

ign_find_package(ignition-common3 COMPONENTS graphics)

ign_find_package(DART
  COMPONENTS
    utils
  PKGCONFIG dart
  PKGCONFIG_VER_COMPARISON >=)

The result of running cmake on this:

-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/lib/ccache/cc
-- Check for working C compiler: /usr/lib/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/lib/ccache/c++
-- Check for working CXX compiler: /usr/lib/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for ignition-common3 -- found version 3.0.0~pre4
-- Searching for dependencies of ignition-common3
-- Looking for dlfcn.h - found
-- Looking for libdl - found
-- Found DL: TRUE  
-- Checking for module 'uuid'
--   Found uuid, version 2.31.1
-- Found UUID: TRUE  
-- Searching for <ignition-common3> component [graphics]
-- Looking for ignition-common3-graphics -- found version 3.0.0~pre4
-- Searching for dependencies of ignition-common3-graphics
-- Looking for ignition-math6 -- found version 6.0.0~pre4
-- Searching for dependencies of ignition-math6
-- Checking for module 'tinyxml2'
--   Found tinyxml2, version 6.0.0
-- Found FreeImage: TRUE (Required is at least version "3.9") 
-- Checking for module 'gts'
--   Found gts, version 0.7.6
-- Found GTS: TRUE  
-- Looking for ignition-common3 - found

-- Could NOT find TINYXML2 (missing: TINYXML2_INCLUDE_DIRS) (found version "6.0.0")
CMake Warning at /usr/local/share/dart/cmake/dart_utilsComponent.cmake:11 (message):
  Cannot retrieve dart-utils because the dependency tinyxml2 could not be
  found.  This usually indicates a broken installation.
Call Stack (most recent call first):
  /usr/local/share/dart/cmake/DARTConfig.cmake:63 (include)
  /usr/local/share/dart/cmake/DARTConfig.cmake:124 (dart_traverse_components)
  /usr/local/share/dart/cmake/DARTConfig.cmake:172 (dart_package_init)
  /home/addisu/ws/ign_base/devel/share/cmake/ignition-cmake2/cmake2/IgnUtils.cmake:188 (find_package)
  CMakeLists.txt:7 (ign_find_package)


-- Found CCD: /usr/include (found version "2.0") 
-- Found FCL: /usr/include (found version "0.5.0") 
-- Found ASSIMP: /usr/include (found version "4.1.0") 
-- Found DART: /usr/local/include  found components:  utils dart 
-- Looking for DART - found

-- Configuring done
-- Generating done
-- Build files have been written to: 

Working example: (ignition-common3 comes after DART)

#!cmake

cmake_minimum_required(VERSION 3.5.1 FATAL_ERROR)
project(test-tinyxml2 VERSION 1.0.0)
find_package(ignition-cmake2 REQUIRED)

ign_find_package(DART
  COMPONENTS
    utils
  PKGCONFIG dart
  PKGCONFIG_VER_COMPARISON >=)

ign_find_package(ignition-common3 COMPONENTS graphics)

The result of running cmake on this:

-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/lib/ccache/cc
-- Check for working C compiler: /usr/lib/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/lib/ccache/c++
-- Check for working CXX compiler: /usr/lib/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found TINYXML2: /usr/include (found version "6.0.0") 
-- Found CCD: /usr/include (found version "2.0") 
-- Found FCL: /usr/include (found version "0.5.0") 
-- Found ASSIMP: /usr/include (found version "4.1.0") 
-- Found DART: /usr/local/include  found components:  utils dart 
-- Looking for DART - found

-- Looking for ignition-common3 -- found version 3.0.0~pre4
-- Searching for dependencies of ignition-common3
-- Looking for dlfcn.h - found
-- Looking for libdl - found
-- Found DL: TRUE  
-- Checking for module 'uuid'
--   Found uuid, version 2.31.1
-- Found UUID: TRUE  
-- Searching for <ignition-common3> component [graphics]
-- Looking for ignition-common3-graphics -- found version 3.0.0~pre4
-- Searching for dependencies of ignition-common3-graphics
-- Looking for ignition-math6 -- found version 6.0.0~pre4
-- Searching for dependencies of ignition-math6
-- Checking for module 'tinyxml2'
--   Found tinyxml2, version 6.0.0
-- Found FreeImage: TRUE (Required is at least version "3.9") 
-- Checking for module 'gts'
--   Found gts, version 0.7.6
-- Found GTS: TRUE  
-- Looking for ignition-common3 - found

-- Configuring done
-- Generating done
-- Build files have been written to: 

Expected behavior:

tinyxml2 should be found in regardless of the order of calls to ign_find_package

Actual behavior:

The order of calls to ign_find_package matters.

Reproduces how often:

100% of the time

Versions

• ignition-common3 (gz11 branch)
• DART v6.7.2
• ignition-cmake2 (gz11 branch)

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

See the documentation here:

https://ignitionrobotics.org/libs/cmake

And how on the main page it says "unreleased":

https://ignitionrobotics.org/home

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

I need to test this to confirm, but it just occurred to me that there may be some fragility in the way the imported targets that get produced by our find-modules will vary based on how the target was made.

When we create the imported target ourselves, we have a rough pattern of naming it PACKAGE::PACKAGE, but when the imported target is made by a package's config-file, it might have some arbitrary name that was chosen by the developer of the package.

In most cases this doesn't seem to be an inherent issue (although it can be a bit of a confusing inconvenience at times, like in this case (#19)), but I suspect this means that if a dependency ever gets reinstalled such that the name of the imported target that would get created by the find-module will come out differently (e.g. the dependency didn't used to provide a config-file, but now it does), then the config-files of all the packages that directly depend on the reinstalled package will need to be reconfigured and reinstalled in order for their config-files to work correctly.

I'll try to test this as soon as I get the chance. I wanted to post this issue right away to make sure I don't forget.

I think the solution would be that all find-modules which allow a config-file to be used should always create an imported target with the same name as the one that would be generated by the config-file.

To make the transition painless for the find-modules that are already providing multiple possible imported target names, we can still create an imported target with our custom name, and just have it link to the target whose name is determined by the dependency's config-file.

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

While using the gz11 branch of ign-math, I had to update our fork of gtest to fix some windows build failures:

• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-math/pull-requests/271/gcc8-use-new-version-of-gtest-to-fix/diff

Today I just noticed that the ign-math2 and ign-math3 branches have loads of compiler warnings related to std::tr1 stuff in gtest, which was the cause of the failure in gz11:

• https://build.osrfoundation.org/view/os_windows/job/ignition_math-ci-ign-math2-windows7-amd64/9/warnings43Result/
• https://build.osrfoundation.org/view/os_windows/job/ignition_math-ci-ign-math3-windows7-amd64/10/warnings43Result/

Oddly, the ign-math4 build does not report any warnings:

• https://build.osrfoundation.org/job/ignition_math-ci-ign-math4-windows7-amd64/24/warnings43Result/

The ign-math2 and ign-math3 branches have slightly different versions of gtest, but ign-math4 has the same version as ign-math3, so I would expect it to have the same compiler warnings. Also, I've reported this here because ign-math4 uses ign-cmake0, while math2/3 have their own cmake code.

Any ideas @mxgrey ?

Original report (archived issue) by Tim Rakowski (Bitbucket: Tim Rakowski).

-- Checking for module 'jsoncpp'
--   Found jsoncpp, version 1.8.4
-- Found JSONCPP: TRUE  
-- Looking for JSONCPP - found
...
[ 82%] Linking CXX shared library libignition-fuel_tools1.so
/usr/bin/ld: cannot find -ljsoncpp_lib

When find_package(jsoncpp CONFIG QUIET) fails and ign_pkg_check_modules(JSONCPP jsoncpp) succeeds, JSONCPP::JSONCPP contains the desired information but JSONCPP_TARGET is still set to jsoncpp_lib (line 35).

I'm not sure if line 35 should be changed to

set(JSONCPP_TARGET JSONCPP::JSONCPP)

or if this should be done somewhere else.

Original report (archived issue) by Anonymous.

[  4%] Performing codecheck step for 'core_no_deps_Release'
cd ....../ign-cmake/build/examples && /usr/local/bin/cmake --build ....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build --target codecheck
make[3]: Entering directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
make[4]: Entering directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
make[5]: Entering directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
make[6]: Entering directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
make[6]: Leaving directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
make[6]: Entering directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
CMakeFiles/codecheck.dir/build.make:57: recipe for target 'CMakeFiles/codecheck' failed
make[6]: *** [CMakeFiles/codecheck] Error 1
make[6]: Leaving directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
CMakeFiles/Makefile2:776: recipe for target 'CMakeFiles/codecheck.dir/all' failed
make[5]: *** [CMakeFiles/codecheck.dir/all] Error 2
make[5]: Leaving directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
CMakeFiles/Makefile2:783: recipe for target 'CMakeFiles/codecheck.dir/rule' failed
make[4]: *** [CMakeFiles/codecheck.dir/rule] Error 2
make[4]: Leaving directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
Makefile:483: recipe for target 'codecheck' failed
make[3]: *** [codecheck] Error 2
make[3]: Leaving directory '....../ign-cmake/build/examples/core_no_deps_Release-prefix/src/core_no_deps_Release-build'
examples/CMakeFiles/core_no_deps_Release.dir/build.make:128: recipe for target 'examples/core_no_deps_Release-prefix/src/core_no_deps_Release-stamp/core_no_deps_Release-codecheck' failed
make[2]: *** [examples/core_no_deps_Release-prefix/src/core_no_deps_Release-stamp/core_no_deps_Release-codecheck] Error 2
make[2]: Leaving directory '....../ign-cmake/build'
CMakeFiles/Makefile2:1880: recipe for target 'examples/CMakeFiles/core_no_deps_Release.dir/all' failed
make[1]: *** [examples/CMakeFiles/core_no_deps_Release.dir/all] Error 2
make[1]: Leaving directory '....../ign-cmake/build'
Makefile:165: recipe for target 'all' failed
make: *** [all] Error 2

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

The headers in the detail/ subfolder are included first in the generated ign_auto_headers.hh file, which is causing some issues. Some would prefer to not have the detail headers included in that auto-generated file.

• https://github.com/ignitionrobotics/ign-cmake/blob/master/cmake/ign_auto_headers.hh.in
• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-math/pull-requests/250/added-cylinder-class/diff#comment-65720980
• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-math/pull-requests/250/added-cylinder-class/diff#comment-69250536

cc @mxgrey @mjcarroll @nkoenig

Original report (archived issue) by Silvio Traversaro (Bitbucket: traversaro).

If you have a cmake project without CXX support enabled (for example if you have a C project), find_package(FreeImage) will fail with an error similar to the following:

-- FreeImage.pc not found, we will search for FreeImage_INCLUDE_DIRS and FreeImage_LIBRARIES
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/ignition-cmake0/cmake0/FindFreeImage.cmake:46 (try_run):
  Unknown extension ".cc" for file

    /home/user/something-superbuild/build/CMakeTmp/test_freeimage.cc

  try_compile() works only for enabled languages.  Currently these are:

    C NONE

  See project() command to enable other languages.
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/CMakeFindDependencyMacro.cmake:65 (find_package)
  /usr/lib/x86_64-linux-gnu/cmake/ignition-common1/ignition-common1-config.cmake:109 (find_dependency)
  /usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake:203 (find_package)
  cmake/BuildGazeboYARPPlugins.cmake:11 (find_package)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:231 (include)
  CMakeLists.txt:70 (find_or_build_package)


-- FreeImage test failed to compile - This may indicate a build system bug
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake:203 (find_package):
  Found package configuration file:

    /usr/lib/x86_64-linux-gnu/cmake/ignition-common1/ignition-common1-config.cmake

  but it set ignition-common1_FOUND to FALSE so package "ignition-common1" is
  considered to be NOT FOUND.  Reason given by package:

  ignition-common1 could not be found because dependency FreeImage could not
  be found.

Call Stack (most recent call first):
  cmake/BuildGazeboYARPPlugins.cmake:11 (find_package)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:231 (include)
  CMakeLists.txt:70 (find_or_build_package)


-- Configuring incomplete, errors occurred!
See also "/home/user/something-superbuild/build/CMakeFiles/CMakeOutput.log".
See also "/home/user/something-superbuild/build/CMakeFiles/CMakeError.log".

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Initially discussed here:

https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-math/pull-requests/268/fix-compilation-using-gcc8-and-add-support/diff#comment-66512565

"it's not properly excluding files; it has the gtest and *_TEST.cc files in the coverage list now"

• https://codecov.io/bb/ignitionrobotics/ign-math/branch/gcc8_c%2B%2B17

Original report (archived issue) by Silvio Traversaro (Bitbucket: traversaro).

I was not able to reproduce it in a simple example, but when using gazebo9 as part of a CMake superbuild, I encounter several of this errors:

 CMake Error at /usr/lib/x86_64-linux-gnu/cmake/ignition-cmake0/cmake0/IgnImportTarget.cmake:88 (add_library):
   add_library cannot create imported target "DL::DL" because another target
   with the same name already exists.
 Call Stack (most recent call first):
   /usr/lib/x86_64-linux-gnu/cmake/ignition-cmake0/cmake0/FindDL.cmake:78 (ign_import_target)
   /usr/share/cmake-3.10/Modules/CMakeFindDependencyMacro.cmake:48 (find_package)
   /usr/lib/x86_64-linux-gnu/cmake/ignition-common1/ignition-common1-config.cmake:108 (find_dependency)
   /usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake:203 (find_package)
   cmake/Buildgazebo-fmi.cmake:12 (find_package)
   /home/straversaro/src/robotology-superbuild/build/install/share/YCM/modules/FindOrBuildPackage.cmake:235 (include)

It seems to me that the problem was solved in ignition-cmake0, but I guess it would make sense to backport the fix to ignition-cmake0 .

Original report (archived issue) by Katawan (Bitbucket: Katawann).

Issue:

I would like to install Ignition Math from the source. I followed the instruction given by Gazebo. After correcting an CMake error about find_package by installing ignition-cmake, I am faced with a new issue when I configure CMake with the command:

cmake ..

I let you know if I find the way to fix this problem

Error:

CMake Error at /usr/local/lib/cmake/ignition-cmake0/cmake0/IgnUtils.cmake:898 (target_compile_features):
The compiler feature "cxx_variable_templates" is not known to CXX compiler

"GNU"

version 4.9.4.
Call Stack (most recent call first):
src/CMakeLists.txt:10 (ign_set_project_public_cxx_standard)

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

In my haste to merge pull request #1, there were some comments that didn't get fully resolved:

• variable for enabling / disabling testing

• location of copyright notice in a module

@mxgrey can you take one more look at these comment threads?

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Checked the Q&A board for common solutions: http://answers.gazebosim.org
  • Checked that your issue isn't already filed.
  • Checked that there is not already an Ignition package that provides the described functionality: https://ignitionrobotics.org/libs

Description

If a package has components with a dependency relationship (such as ign-physics-dartsim-plugin, which depends on ignition-physics-sdf and ignition-physics-mesh), then then all the components must be listed in the ign_find_package call and in a proper order. The following is a workaround for this issue in ign-gazebo:

• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-gazebo/pull-requests/105/find-mesh-component-of-physics/diff

Steps to Reproduce

I've demonstrated this issue with some examples committed to branch find_component_order_working and branch find_component_order. The find_component_order_working branch creates a package component_deps that has two components: parent and child, and the child component links against the parent. There is a second package called use_component_deps1 that makes an ign_find_package call for component_deps specifying both components parent child. This example builds fine:

1. hg up find_component_order_working
2. mkdir build && cd build && cmake ..
3. make (successful)

Now on branch branch find_component_order, another example named use_component_deps2 is added that differs from use_component_deps1 only in the order that components are specified in the ign_find_package call, but it fails to build:

1. hg up find_component_order
2. mkdir build && cd build && cmake ..
3. make (unsuccessful)

Expected behavior:

I would expect the examples to build regardless of the order in which components are specified. Furthermore, I would that specifying a component would cause dependent components to be included as well (as in the ign-physics example mentioned above).

Actual behavior:

ign_find_package is sensitive to the order of specified components when there is a dependent relationship, and dependent components must all be listed.

Reproduces how often:

100%

Versions

ign-cmake1 and ign-cmake2

Additional Information

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Windows doesn't seem to like the IGN_DEPRECATED define.

On ign-math, using it like this:

       public: void Translate(const Vector3<T> &_t)
      IGN_DEPRECATED(4)
      {
        this->SetTranslation(_t);
      }

Resulted on this error (there are 3 instances using deprecate):

D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(186): error C2143: syntax error: missing ';' before 'function-style cast'
D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(887): note: see reference to class template instantiation 'ignition::math::Matrix4<T>' being compiled
D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(187): error C2059: syntax error: ''
D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(187): error C2334: unexpected token(s) preceding '{'; skipping apparent function body
D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(206): error C2143: syntax error: missing ';' before 'function-style cast'
D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(207): error C2059: syntax error: ''
D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(207): error C2334: unexpected token(s) preceding '{'; skipping apparent function body
D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(403): error C2143: syntax error: missing ';' before 'function-style cast'
D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(404): error C2059: syntax error: ''
D:\Jenkins\workspace\ignition_math-ci-pr_any-windows7-amd64\workspace\ign-math\include\ignition/math/Matrix4.hh(404): error C2334: unexpected token(s) preceding '{'; skipping apparent function body
NMAKE : fatal error U1077: 'C:\PROGRA~2\MIB055~1\2017\COMMUN~1\VC\Tools\MSVC\1411~1.255\bin\Hostx86\x64\cl.exe' : return code '0x2'

See this ign-math PR for more context.

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

https://cmake.org/cmake/help/v3.0/module/ExternalProject.html

There is an example test here:

• https://bitbucket.org/scpeters/ign-cmake/commits/e59950f36b14b73536ed22fdd3440b7566fef551

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

We have merged support for ign-transport on windows and need to make a release in order to move forward with ign-transport.

It looks like there are a few more pull requests needed for ign-fuel-tools:

• pull request #33
• pull request #35
• pull request #36

Should we wait for ign-fuel-tools support in this release?

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

The utilities/SuppressWarning.hh headers added in pull request #101 are not represented in any ignition pkg-config .pc files. I just noticed this while working on a test for the homebrew formula of ign-plugin, and when trying to use it's compiler flags, the utilities folder is missing from the include flags.

cc @mxgrey

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

• ////////////////////////////////////////////////// inside a code block is ignored.
• \brief is extracted from the code block and rendered before the code snippet. Probably because is a Doxygen reserved word.

Here's the result of generating documentation for this tutorial:

#!python


 # Test

 Here's a code snippet:

 ```{.cpp}
 //////////////////////////////////////////////////
 /// \brief Provide an "echo" service.
 bool srvEcho(const ignition::msgs::StringMsg &_req,
   ignition::msgs::StringMsg &_rep)
 {
   // Set the response's content.
   _rep.set_data(_req.data());

   // The response succeed.
   return true;
 }

And this is how it looks:

![code_snippet_1.png](https://osrf-migration.github.io/ignition-gh-pages/data/bitbucket.org/repo/Gg8npGe/images/2511738915-code_snippet_1.png)

Here's the result of generating documentation for this tutorial:

#!python

Test

The same tutorial without the separator and doxygen tag:

bool srvEcho(const ignition::msgs::StringMsg &_req,
  ignition::msgs::StringMsg &_rep)
{
  // Set the response's content.
  _rep.set_data(_req.data());

  // The response succeed.
  return true;
}

![code_snippet_2.png](https://osrf-migration.github.io/ignition-gh-pages/data/bitbucket.org/repo/Gg8npGe/images/176048270-code_snippet_2.png)

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

Apologies in advance for the wall-of-text.

The original motivation for creating ign-cmake was to systematically ensure consistent build behavior across all the ignition projects, in a way that is maintainable and scalable.

Even though the ign-cmake package is still in development, it's had some very tangible benefits: we now have four projects (ign-math, ign-common, ign-msgs, and ign-transport) with robust build systems across all of our supported platforms and consistent package behavior across all of the projects. If we ever decide to change our packaging behavior or if we ever need to fix a build system bug, we can take care of it in ign-cmake, and all the ignition projects will benefit the next time they configure. Future and upcoming projects will experience these benefits as well.

However, we want to have consistency across all the ignition projects in more ways than just their build system and packaging. The most obvious example is the PIMPL pattern, which is a design pattern that we aim to use across all the ignition projects to achieve maximum flexibility in our development cycles without needing to be concerned about breaking ABI.

The forcing function that prompted me to make this proposal was in a recent ign-transport pull request, we found ourselves repeatedly writing boilerplate move and copy constructors, plus move and copy assignment operators for just about every darn interface class (here's a sampling from that one pull request: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19).

The worst part is, even with all that effort in manually creating all those constructors and assignment operators, some of the classes in that pull request still don't have proper copy and move semantics, simply because we have not yet noticed that their copy/move constructors/operators are missing.

That's when I remembered some design utilities promoted by Scott Meyers which makes the PIMPL pattern so very much more bearable. Here's a tl;dr of that article:

Instead of using a plain std::unique_ptr<Implementation> to contain the implementation object, you can have a impl_ptr<Implementation> which takes care of creating the copy and move constructors for your interface class. To make that more concrete, your class definition would look like this:

class MyClass
{
  public: /* Interface functions go here */

  private: class Implementation;
  private: ImplPtr<Implementation> dataPtr;
};

Then in the source file, your constructor would look like this:

MyClass::MyClass( /* constructor args */ )
  : dataPtr(MakeImpl<Implementation>(/* constructor args */))
{
  // Do nothing
}

This will allow MyClass to automatically create a copy constructor, move constructor, copy operator, and move operator, and all you have to do is replace std::unique_ptr with ImplPtr and new Implementation with MakeImpl<Implementation>. Note that we can also have a UniqueImplPtr which will allow moving but not copying, for classes that are not copyable. The catch, of course, is you need to have access to the header that defines ImplPtr and MakeImpl.

Since it's a single header file, the brute force approach would be to write the header and then drop it into each project. That's a viable solution if we're confident that we'll never ever have to make any changes to the implementation, but that's a very risky assumption to make.

Ideally, we would want the ImplPtr to be available in every project from a single source. We already have a project which is a required dependency of every ignition project: ign-cmake. If we were to consider the goal of ign-cmake to be achieving consistent, maintainable, scalable development (not just build+packaging behavior) across all the ignition projects, then it would make sense to have it provide a small set of C++ utilities that could be used across all projects to keep behavior and development consistent between them.

I can think of three utilities which would make sense to share across all projects right away: (1) the pimpl class mentioned here, (2) the warning suppression system which is currently in ign-common, and (3) the Console utility currently in ign-common. These are things that all project would benefit from:

1. Anything that can make PIMPL easier to stomach is a good thing.

2. We're repeatedly dealing with the same compiler warnings across every project. This would give us a clean way to handle those consistently everywhere.

3. Having the Console class and its error/warning macros as base utilities would allow us to have consistent status, warning, and error messaging behavior across all the libraries, instead of having some print proper messages while others print plain, unformatted messages.

We could also consider the Filesystem from ign-common, but I don't think that's as basic of a utility (and it will probably be replaced by the C++17 filesystem soon anyway).

Why not just use ign-common?

Right now, ign-common would be more aptly named ign-miscellaneous. Most of its content is not common to all projects, and it would be unreasonable to have all projects depend on it, even after it's been split into components.

ign-cmake is already a required dependency. Putting these utilities into ign-cmake will make them accessible to all projects right away, without introducing any new dependencies.

Then could we really call this project ign-cmake anymore?

Maybe not.

I would propose that we add these utilities to ign-cmake as a library called ignition-utilities (or maybe ignition-utils, or some variation on that). When each project calls find_package(ignition-cmake1) it will import a target for the ignition-utilities library, and ign-cmake can automatically link each project library against the utilities target. Consumer projects wouldn't have to change anything in their build scripts.

Then, when we're approaching the hypothetical release of ignition-cmake1, we can decide whether we want to keep using the name ignition-cmake. Maybe by then, ign-common will be rid of its miscellaneous components, and we can have ign-cmake take over the name ign-common. Otherwise, we could consider renaming ign-cmake to something like ign-utilities, ign-utils, ign-root, ign-base, or any other suggestions that people have. Or we could just keep the name as ign-cmake and accept the slight misnomer of the project.

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

Steps to reproduce:

• Compile your Ignition project with -DCMAKE_BUILD_TYPE=coverage
• Run make doc:

#!python

make: *** No rule to make target 'doc'.  Stop.

Original report (archived issue) by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

Proposal

# find ignition-math3, or ignition-math4
# copy all variables prefixed with the found project name into variables prefixed with ${OUTPUT_VAR}
ign_find_package(
    OUTPUT_VAR
        some-math-version
    ONE_OF
        ignition-math4
        ignition-math3
    REQUIRED)

 # ...

target_link_libraries(my_lib ${some-math-version_LIBRARIES})

Developing on the default branch of ignition projects has one minor annoyance that occurs fairly frequently. The major version being bumped on one branch breaks the build of every downstream project. If the upstream project doesn't have a release then downstream must choose between everything-from-source builds being broken, or CI being broken. To get around this some projects have been finding either ignition-math3 or ignition-math4.

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Initially noted in pull request #61:

• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-cmake/pull-requests/61/install-cmake-files-to-share-instead-of/diff#comment-61329769

From @_jrivero_: I've notice that when installing the files using DESTDIR (i.e. DESTDIR=/tmp/foo make install) there are some $HOME paths that end up being installed there, but the problem is also present in default

Reply from @mxgrey:

To elaborate on Jose's comment, it seems that trying to use make DESTDIR=/dest/dir install has some rather problematic behavior. Apparently DESTDIR=/dest/dir will prefix the install paths (including CMAKE_INSTALL_PREFIX) with /dest/dir. So if CMAKE_INSTALL_PREFIX was /usr/local, then make DESTDIR=/dest/dir install will have the installed files go to /dest/dir/usr/local.

This is problematic because the example projects (which are set to be installed to /path/to/build/folder/install) will inadvertently get installed to /dest/dir/path/to/build/folder/install, which is outside of the build directory.

We need a way of removing the build and installation of the example projects from the build and installation of all (preferably by tying those to make test instead), or else we won't be able to correctly support make DESTDIR=<path> install.

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Since branch coverage was merged in pull request #46 and released in version 0.5.0, I've noticed at least one instance of make coverage hanging in a bitbucket pipeline:

• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-common/pull-requests/59/expanding-the-functionality-of-the-plugin/diff
• pipeline timed out after 120 minutes, so I reduced the timeout to 10 minutes in https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-common/commits/c0643d62603ddb835ccb5c24f301a0fe20150a01 (gazebosim/gz-common@f3494ca)

Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).

The ign_install_executable calls the manpage macro. However, this macro is not defined unless the IgnRonn2Man.cmake file is included. Including IgnRonn2Man results in another error:

ignition-cmake1/cmake1/IgnRonn2Man.cmake:57 (ADD_DEPENDENCIES):
  Cannot add target-level dependencies to non-existent target "man".

Original report (archived issue) by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

While cleaning up a docker image based on 16.04 I had installed libprotobuf-dev and protobuf-compiler but accidentally removed libprotoc-dev.

The output at generate time is

-- Found Protobuf: /usr/lib/x86_64-linux-gnu/libprotobuf.so (Required is at least version "2.3.0") 
-- Looking for Protobuf - found

but the output at build time is

-- Build files have been written to: /workspace/ws_ign/build_isolated/ign_msgs
==> '. /workspace/ws_ign/build_isolated/ign_msgs/cmake__build.sh && /usr/bin/make -j8 -l8' in '/workspace/ws_ign/build_isolated/ign_msgs'
src/CMakeFiles/ign_msgs_gen.dir/build.make:120: *** target pattern contains no '%'.  Stop.
CMakeFiles/Makefile2:1186: recipe for target 'src/CMakeFiles/ign_msgs_gen.dir/all' failed

Line 120 in build.make is src/ign_msgs_gen: protobuf::libprotoc-NOTFOUND

I'd like the the generate step to error with "libprotoc not found". How could that be accomplished? Does it warrant it's own find module? Or would it fit better as a COMPONENT of FindIgnProtobuf?

Original report (archived issue) by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

Stumbled on some super useful cmake documentation while trying to respond to ros/console_bridge#52.

• https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages
• https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html#find-modules

Takeaways after reading:

• CMake recommends that project variables (Xxx_INCLUDE_DIRS, Xxx_LIBRARIES) should only be provided by find modules or <project>-config.cmake files that existed before the modern target name approach and are trying to be backwards compatible. Future ignition projects don't need to (and shouldn't) set them at all.
• If ignition-cmake provides "standard variables", code we control should not use them. Other ignition projects and Tutorials/examples should use target names.
  • Do target_link_libraries(ignition-common1 PUBLIC ignition-math4::ignition-math4)
  • Don't do target_link_libraries(ignition-common1 PUBLIC ${ignition-math4_LIBRARIES}
• The variables are quirky. <project>_LIBRARIES should contain absolute paths to any libraries, but ignition-cmake is currently setting them to the imported target name instead.

Original report (archived issue) by Rich Mattes (Bitbucket: richmattes).

ignition-cmake's CMake modules are being installed to IGN_LIB_INSTALL_DIR, but the scripts themselves don't appear to have any architecture dependent features.

I recommend shifting the installation directory to /usr/share/ignition-cmake0 to support the creation of architecture independent packages downstream.

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

It's tricky to get UNIT_ign_TEST configured and working properly on multiple platforms. We currently have a working example in ign-transport4, and the following pull request ports these changes to ign-msgs1, but it is a bit complicated and spread over quite a few files.

• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-msgs/pull-requests/62/fix-unit_ign_test-on-homebrew/diff

It would be nice if we could provide some helpers to simplify this.

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

Here's an example of Markdown that contains a table:

#!python

# Tables

Here's a table:

| Tables        | Are           | Cool  |
| ------------- |:-------------:| -----:|
| col 3 is      | right-aligned | $1600 |
| col 2 is      | centered      |   $12 |
| zebra stripes | are neat      |    $1 |

This is how it's rendered after running make doc:

And this how is suppose to look:

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

Adding a debug postfix (such as d) onto versions of libraries that were built in debug mode is helpful for installing release and debug versions of the same library side-by-side.

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

It turns out that the compiler flags -std=c++14 and -std=gnu++14 do not behave well together in a single compilation call. In most cases the issue won't be noticed, but when numeric literals show up, a bug is triggered.

We get the -std=gnu++14 flag automatically from cmake when we request C++14 features from target_compile_features(~). We can explicitly disable this behavior by setting CMAKE_CXX_EXTENSIONS to off (by default, it is set to on). Turning extensions off will force cmake to use -std=c++14 instead of -std=gnu++14.

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

Installing Ign CMake default. This is the error:

#!python

-- Looking for Protobuf - not found

...

-- BUILD ERRORS: These must be resolved before compiling.
-- 	Missing: Protobuf
--  END BUILD ERRORS

I believe the error has been introduced by pull request #81. If I comment the block checking for components, Protobuf is found. The problem appears to be that that protobuf targets (e.g.: protobuf::libprotobuf) don't exist, and then, we set Protobuf_FOUND to false. In the old version of the code, we were creating the imported targets. Now, we're not doing it as Protobuf_FOUND is false.

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

We frequently need to provide tests with the full path of their own build directory. This may be necessary for a test so that it can run a helper program or find a plugin library at run time.

Historically, we have solved this by generating a test_config.h file at configuration time, and providing it with a macro named something like IGN_CONFIG_PATH. However, this cannot work for multi-configuration generator types, such as the Visual Studio generators. The reason is the header gets created at configuration time, but a multi-configuration generator cannot know what directory a binary will be built in until generation time (which comes after configuration time).

To make ign-common plugins testable in Visual Studio, I came up with a gross solution where we create a custom command that injects text into a file. Custom commands in cmake are able to use generator expresisons, so the path can be identified and supplied at generation time. I was never satisfied with this solution, but I couldn't think of a better one at the time.

I recently came up with something that might be a little nicer: Instead of generating a header, we can use target_compile_definitions(~) to provide the tests with this path information. target_compile_definitions(~) is able to handle generator expressions, so we don't need to do weird things with configuring headers at generation time using add_custom_command(~).

To do this, we could simply add the following line into the loop inside of ign_build_tests(~):

target_compile_definitions(${BINARY_NAME} PRIVATE IGN_BINARY_PATH="$<TARGET_FILE_DIR:${BINARY_NAME}>")

At that point, each test can know what its own directory path is by invoking the macro IGN_BINARY_PATH.

If certain specific tests need to know the paths of other targets, that can be handled on a case-by-case basis by doing:

target_compile_definitions(<specific_test_target_name> PRIVATE IGN_PATH_TO_OTHER_THING="$<TARGET_FILE_DIR:${OTHER_THING}>")

as long as we ensure that the name IGN_PATH_TO_OTHER_THING does not collide with any other compile definitions.

I think this would be the most robust and elegant way to ensure that our tests work regardless of what type of generator is used to configure and build them.

The one downside (that I can think of) is that the definitions (nay, the very existence) of these macros would be hard for developers to be aware of unless they're using a pretty good IDE (e.g. Qt Creator).

If anyone else likes this idea, I can move forward on it. I'd be able to use ign-common as a good example for usage.

Original report (archived issue) by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

The pkg-config file ignition-cmake generates for for ignition-common uses spaces to separate the entries in Requires. man pkg-config says Requires and Requires.private are "a comma-separated list of packages".

prefix=/workspace/ws_ign/install_isolated/ign_common
libdir=${prefix}/lib
includedir=${prefix}/include/ignition/common0

Name: Ignition common
Description: A set of common classes for robot applications
Version: 0.5.0~pre1
Requires: ignition-math4 uuid gts libswscale libavdevice >= 56.4.100 libavformat libavcodec libavutil
Requires.private: tinyxml2
Libs: -L${libdir} -lignition-common0 
Libs.private: -ldl
CFlags: -I${includedir} 

Original report (archived issue) by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero).

With the current state it is impossible to define a version suffix to the declared version. If you try to just add the version in ign_configure_project(....) call but cmake does not expect an string (just numeric values) in the diferent VERSION clauses that will consume the information from the previous call.

What I think that we need to change: at least the version used in CPack so we get a different tarball name than the stable version (I made an ugly hack in msgs today but could serve as an example).

Speaking about the rest of places using the version (like the cmake module) I think that most of our developers and users would expect the ~pre, ~alpha or ~beta version to behave in the same way that the stable version.

The fine tunning versioning can be done downstream in debian metadata. I'm afraid that I won't be able to implement it during this week, sorry @mxgrey.

Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).

make codecheck could always generate junit xml, or we could make a new target that generates only junit xml.

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

This is for informational purposes only; we do not support this version of OS X.

The default clang compiler on osx 10.10 does not support the cxx11 compiler feature cxx_thread_local. So if you try to configure a project with the line ign_set_project_public_cxx_standard(11), it will fail to configure.

$ clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

CMake Error at /Users/scpeters/ws/ignition/devel/lib/cmake/ignition-cmake0/cmake0/IgnUtils.cmake:941 (target_compile_features):
  target_compile_features The compiler feature "cxx_thread_local" is not
  known to CXX compiler

  "AppleClang"

  version 7.0.2.7000181.
Call Stack (most recent call first):
  src/CMakeLists.txt:10 (ign_set_project_public_cxx_standard)

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

Example of markdown:

#!python

# A test

This is a an unordered list:

- Item
+ Item
* Item

And this is the current output:

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

There are some very nice helper functions and macros for getting the names of source and test files for creating libraries, but they seems to not be that helpful for projects that use qt and need to use the moc compiler on the header files, for example ignition-gui:

https://github.com/ignitionrobotics/ign-gui/blob/d0ce8c1a0b29446e6a1720c459ac8b2a134dfaad/include/ignition/gui/CMakeLists.txt

This currently works by creating the core library in the include/ignition/gui/CMakeLists.txt so that it can invoke the moc compiler on the qt header files. The source files from src are declared with PARENT_SCOPE so they can be added to the library from the include folder.

It currently works, but it seems like there's room for improvement.

Original report (archived issue) by Anonymous.

I have been trying to update an older ROS-Gazebo project, to gazebo 9 that is using ignition math:

https://github.com/ethz-asl/rotors_simulator

Currently I am running Ubuntu 18.04, and Gazebo 9.1 and cmake 3.10.2.

When I compile the code get an error from CMAKE, that looks like this:

CMake Error at /home/martin/ros_sim_drone/src/rotors_simulator/rotors_gazebo_plugins/CMakeLists.txt:26 (target_link_libraries):
  Error evaluating generator expression:

    $<TARGET_PROPERTY:UUID::UUID,INTERFACE_INCLUDE_DIRECTORIES>

  Target "UUID::UUID" not found.

The whole response looks like this:

Errors     << rotors_gazebo_plugins:check /home/martin/ros_sim_drone/logs/rotors_gazebo_plugins/build.check.002.log                                                                                        
CMake Warning (dev) at /usr/share/cmake-3.10/Modules/FindBoost.cmake:911 (if):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "chrono" will no longer be dereferenced when the
  policy is set to NEW.  Since the policy is not set the OLD behavior will be
  used.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/FindBoost.cmake:1558 (_Boost_MISSING_DEPENDENCIES)
  /usr/share/OGRE/cmake/modules/FindOGRE.cmake:318 (find_package)
  /usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake:175 (find_package)
  CMakeLists.txt:20 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:28 (add_library):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target "rotors_gazebo_bag_plugin" links to target "UUID::UUID" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:28 (add_library):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target "rotors_gazebo_bag_plugin" links to target "UUID::UUID" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at /home/martin/ros_sim_drone/src/rotors_simulator/rotors_gazebo_plugins/CMakeLists.txt:29 (target_link_libraries):
  Error evaluating generator expression:

    $<TARGET_PROPERTY:UUID::UUID,INTERFACE_INCLUDE_DIRECTORIES>

  Target "UUID::UUID" not found.


CMake Error:
  Error evaluating generator expression:

    $<TARGET_PROPERTY:UUID::UUID,INTERFACE_INCLUDE_DIRECTORIES>

  Target "UUID::UUID" not found.


CMake Error:
  Error evaluating generator expression:

    $<TARGET_PROPERTY:UUID::UUID,INTERFACE_INCLUDE_DIRECTORIES>

  Target "UUID::UUID" not found.


CMake Error at /home/martin/ros_sim_drone/src/rotors_simulator/rotors_gazebo_plugins/CMakeLists.txt:29 (target_link_libraries):
  Error evaluating generator expression:

    $<TARGET_PROPERTY:UUID::UUID,INTERFACE_INCLUDE_DIRECTORIES>

  Target "UUID::UUID" not found.


make: *** [cmake_check_build_system] Error 1

My cmake file currently look like this:

cmake_minimum_required(VERSION 2.8.3)
project(rotors_gazebo_plugins)


find_package(catkin REQUIRED COMPONENTS
    cmake_modules
    geometry_msgs
    mav_msgs
    rosbag
    roscpp
    gazebo_ros
    rotors_comm
    rotors_control
    std_srvs
    tf
  )

find_package(Boost REQUIRED)
find_package(Eigen3 REQUIRED)
find_package(gazebo REQUIRED)
find_package(Protobuf REQUIRED)

link_directories(${GAZEBO_LIBRARY_DIRS})
include_directories(include ${Boost_INCLUDE_DIR} ${catkin_INCLUDE_DIRS} ${Eigen3_INCLUDE_DIRS} ${GAZEBO_INCLUDE_DIRS})

#message(AUTHOR_WARNING "${GAZEBO_INCLUDE_DIRS}")

add_library(rotors_gazebo_bag_plugin SHARED src/gazebo_bag_plugin.cpp)
target_link_libraries(rotors_gazebo_bag_plugin ${catkin_LIBRARIES} ${GAZEBO_LIBRARIES})

#message(AUTHOR_WARNING "${GAZEBO_LIBRARIES}")

catkin_package(
  INCLUDE_DIRS include
  LIBRARIES ${PROJECT_NAME} rotors_gazebo_motor_model rotors_gazebo_controller_interface
  CATKIN_DEPENDS geometry_msgs mav_msgs rosbag roscpp rotors_comm rotors_control std_srvs tf
  DEPENDS EIGEN3 GAZEBO
)

Printing out my ${GAZEBO_LIBRARIES} I got this result:

BulletSoftBody;BulletDynamics;BulletCollision;LinearMath;/usr/lib/x86_64-linux-gnu/libSimTKsimbody.so;/usr/lib/x86_64-linux-gnu/libSimTKmath.so;/usr/lib/x86_64-linux-gnu/libSimTKcommon.so;/usr/lib/x86_64-linux-gnu/libblas.so;/usr/lib/x86_64-linux-gnu/liblapack.so;/usr/lib/x86_64-linux-gnu/libblas.so;pthread;rt;dl;m;/usr/lib/x86_64-linux-gnu/libgazebo.so;/usr/lib/x86_64-linux-gnu/libgazebo_client.so;/usr/lib/x86_64-linux-gnu/libgazebo_gui.so;/usr/lib/x86_64-linux-gnu/libgazebo_sensors.so;/usr/lib/x86_64-linux-gnu/libgazebo_rendering.so;/usr/lib/x86_64-linux-gnu/libgazebo_physics.so;/usr/lib/x86_64-linux-gnu/libgazebo_ode.so;/usr/lib/x86_64-linux-gnu/libgazebo_transport.so;/usr/lib/x86_64-linux-gnu/libgazebo_msgs.so;/usr/lib/x86_64-linux-gnu/libgazebo_util.so;/usr/lib/x86_64-linux-gnu/libgazebo_common.so;/usr/lib/x86_64-linux-gnu/libgazebo_gimpact.so;/usr/lib/x86_64-linux-gnu/libgazebo_opcode.so;/usr/lib/x86_64-linux-gnu/libgazebo_opende_ou.so;/usr/lib/x86_64-linux-gnu/libgazebo_ccd.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_signals.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_program_options.so;/usr/lib/x86_64-linux-gnu/libboost_regex.so;/usr/lib/x86_64-linux-gnu/libboost_iostreams.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libprotobuf.so;-lpthread;/usr/lib/x86_64-linux-gnu/libsdformat.so;ignition-math4::ignition-math4;optimized;/usr/lib/x86_64-linux-gnu/libOgreMain.so;debug;/usr/lib/x86_64-linux-gnu/libOgreMain.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libpthread.so;optimized;/usr/lib/x86_64-linux-gnu/libOgreTerrain.so;debug;/usr/lib/x86_64-linux-gnu/libOgreTerrain.so;optimized;/usr/lib/x86_64-linux-gnu/libOgrePaging.so;debug;/usr/lib/x86_64-linux-gnu/libOgrePaging.so;ignition-math4::ignition-math4;ignition-transport4::ignition-transport4;ignition-msgs1::ignition-msgs1;ignition-common1::ignition-common1;ignition-fuel_tools1::ignition-fuel_tools1

Diging a bit futher I found the following lines in gazebo-config.cmake

# Find Ignition Math
find_package(ignition-math4 REQUIRED)
list(APPEND GAZEBO_INCLUDE_DIRS ${IGNITION-MATH_INCLUDE_DIRS})
list(APPEND GAZEBO_LIBRARY_DIRS ${IGNITION-MATH_LIBRARY_DIRS})
list(APPEND GAZEBO_LIBRARIES ${IGNITION-MATH_LIBRARIES})

This lead me to "ignition-math4/ignition-math4-config.cmake" where I found this line:

set(ignition-math4_LIBRARIES ignition-math4::ignition-math4)

These libray difinitions for ignition seems to be my current problem with my projects cmake script. I am unsure how this fix it, to get the correct library links for my project.

Original report (archived issue) by Rich Mattes (Bitbucket: richmattes).

While packaging for fedora, I noticed there's no license file in the repository. I found Apache 2 and BSD licensed files in the source tree - please add LICENSE/COPYING files as applicable.

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

As we add components, the code checking scripts will need to be made aware of the component source directories, as seen in this commit (gazebosim/gz-common@9df146d).

We could consider using ign-cmake to generate these scripts at configure time to avoid the need to maintain these scripts independently for each project.

The only catch (that I can think of) is that the build would need to be configured for a project (but compiling would not be necessary) before the code checking can be performed. That shouldn't be an issue for our CI systems, so I don't think it's much of a cost.

Original report (archived issue) by Silvio Traversaro (Bitbucket: traversaro).

While compiling ign-cmake on Windows, I noticed that the default CMAKE_INSTALL_PREFIX was C:/Program Files/Project instead of the usual C:/Program Files/ignition-cmake0. Apparently this is due to a CMake requirement about the project command:

The top-level CMakeLists.txt file for a project must contain a literal, direct call to the project() command; loading one through the include() command is not sufficient. If no such call exists CMake will implicitly add one to the top that enables the default languages (C and CXX).

See https://cmake.org/cmake/help/v3.5/command/project.html .

The default CMAKE_INSTALL_PREFIX issue in Windows is not a big problem, but it would be interesting to understand if this initial implicit call to project(Project LANGUAGES CXX C) is creating any other problem. For example the problem for which a workaround was added in https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-cmake/commits/189c956decb09f1f58a40cccd1ec861e3f161590?at=default could be related to this. (2a08505)

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

I just noticed that the doxygen tags are ending up in directories with duplicate ignition such as:

/usr/local/share/ignition/ignition-common1_1/ignition-common1.tag.xml

Should that be going to the following instead?

/usr/local/share/ignition/common1/ignition-common1.tag.xml

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Our test coverage is harder to interpret since we merged branch coverage support in pull request #46. Previously, line of code would be marked green (covered) or red (uncovered). Now there are many lines marked yellow, and it is not clear to me why that is the case. Some of the yellow lines (like ignition/math/Filter.hh:92 or ign-math/src/SignalStat.cc:67) don't appear to have any branching at all.

Does anyone else know how to interpret these?

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Many ignition packages are now using the doxygen functionality from ign-cmake, but they have nearly identical cmake code in doc/CMakeLists.txt:

• https://github.com/ignitionrobotics/ign-math/blob/ba15f61704aec1224462cf8e950f01465672c766/doc/CMakeLists.txt
• https://github.com/ignitionrobotics/ign-common/blob/1ee6b1f8bd8312222c1b5fe6e2ff6b48fc5b6d1a/doc/CMakeLists.txt
• https://github.com/ignitionrobotics/ign-msgs/blob/f0aaa88d732ff718949496931a9792a30ac4f3da/doc/CMakeLists.txt
• https://github.com/ignitionrobotics/ign-transport/blob/1448e5c4a310b4dd93f7f2fec5232e7ace8e8dc7/doc/CMakeLists.txt

The only difference I can see are in setting the IGNITION_DOXYGEN_TAGFILES variable.

# from ign-msgs:
set(IGNITION_DOXYGEN_TAGFILES
  "\"${IGNITION-MATH_DOXYGEN_TAGFILE} = ${IGNITION-MATH_API_URL}\"")

# from ign-transport
set(IGNITION_DOXYGEN_TAGFILES
  "\"${IGNITION-MSGS_DOXYGEN_TAGFILE} = ${IGNITION-MSGS_API_URL}\"")

We could make IGNITION_DOXYGEN_TAGFILES an input parameter.

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

For more context: https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-cmake/pull-requests/68/properly-mark-internal-cmake-cache/diff#comment-62213951

Original report (archived issue) by Katawan (Bitbucket: Katawann).

Issue:

I would like to install Ignition Math from the source. I followed the instruction given by Gazebo. But at the point 4, when I try to configure CMake, it can not find the package of ignition (using find_package) and I can not find this file anywhere.

If you have any suggestions !

Errors:

CMake Error at CMakeLists.txt:7 (find_package):
By not providing "Findignition-cmake0.cmake" in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
"ignition-cmake0", but CMake did not find one.

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

ignition-cmake0Config.cmake
ignition-cmake0-config.cmake

Add the installation prefix of "ignition-cmake0" to CMAKE_PREFIX_PATH or
set "ignition-cmake0_DIR" to a directory containing one of the above files.
If "ignition-cmake0" provides a separate development package or SDK, be
sure it has been installed.

-- Configuring incomplete, errors occurred!

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

I was reading through other code, and I noticed that IgnConfigureProject.cmake tries to call a bash script called case_sensitive_filesystem, but that file is not in this repository. I'm guessing this code was copied from gazebo, which does have this file:

• https://bitbucket.org/osrf/gazebo/src/default/tools/case_sensitive_filesystem

This file would need to be added to ign-cmake, installed, and the find path updated.

It is not urgent though.

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

This is a variant of the bug fixed in pull request #56, for which a test was added in pull request #58. In the original, a package core_child that depends on core_no_deps wasn't exporting this dependency information in the pkg-config file. This bug is a variant in which core01_child uses ign-cmake1, while the dependency core01_no_deps uses ign-cmake0. In this case, core01_child is not exporting its dependency on core01_no_deps in the .pc file. I've made an example to illustrate this in branch requires_01, though I'm not sure if we will merge it to default, since it requires ignition-cmake0. It is helpful though in illustrating the problem and testing fixes.