Symbol collision for BUILD_TYPE_* variables with dart

[osrf-migration]

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

---

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:

"BUILD_TYPE_RELEASE" redefined

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

• dart/config.hpp.in
• cmake/gazebo_config.h.in

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.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

cc @mxgrey

[osrf-migration]

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

---

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.

[osrf-migration]

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

---

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.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

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

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

pull request #2840

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

now see pull request #2846 instead

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

• changed state from "new" to "resolved"

symbols renamed to GAZEBO_BUILD_TYPE_* in pull request #2846