Symbol collision for `BUILD_TYPE_*` variables with dart

Create issue
Issue #2343 resolved
Steve Peters created an issue

We recently started installing dart for gazebo CI jobs on Ubuntu, and I just noticed a new compiler warning in the Release build of the default branch:


I believe this occurs because these variables are exposed in similar header files generated by cmake for both gazebo and dart:

We usually don't see this conflict because gazebo uses the RelWithDebInfo build type by default, but the conflict occurs when both build in Release mode.

I think there may be some other symbol collisions as well, like HAVE_BULLET.

Comments (7)

  1. Michael Grey

    Good to know. I wonder how many other cmake-based projects run into this issue, and how others have handled it.

    One solution is to qualify the macros with the project name (e.g. DART_BUILD_TYPE_RELEASE and GAZEBO_BUILD_TYPE_RELEASE), but the problem with that is: What if DART were to provide some header-based implementations (e.g. templates) whose compilation varies based on the build type? Those headers would want to know what build type is being used by Gazebo.

    Maybe we could instead mask these variables with some #ifndef ... statements. I can investigate whether cmake has an automated way of doing that.

  2. Michael Grey

    Actually, after some further thought, these files are configured at config time, which means the value set by Gazebo can't affect the DART header. That would suggest that namespacing these macros would be the right way to go. However, I'm a bit perplexed about how these macros would affect things when multiple build types are installed at once. The macro that's set for the header you use might not match the build type of the library you link against.

    I wonder if both DART and Gazebo should keep these macros private rather than have them in a public-facing header.

  3. Steve Peters reporter

    yeah, we should probably just move those variables to a private header. gazebo just seems to use them in some of the tests

    note that we have them in most of the ignition projects too

  4. Log in to comment