Don't install test header files in rviz_rendering.

[clalancette]

This change started as a relatively simple try at not installing
test includes when installing rviz_rendering. As you can see,
it ballooned into quite a large change, so here is an explanation
of why.

We shouldn't install test include header files when installing
the package; that just ends up on the end user system, and
is a non-supported API. Worse, we don't want to compile test
code in our main library. Yet rviz_rendering is currently doing
both of these things.

Unfortunately, it is somewhat tricky to make that code and header
file private. The problem is that that test code is used in
rviz_rendering, rviz_common, rviz_default_plugins, and
rviz_rendering_tests.

One solution might be to extract that test code into its own
package, and then have all of the other packages depend on it.
The problem is that that test package would both be depended
on by rviz_rendering (for tests), and depends itself on rviz_rendering
(for its functionality), creating a dependency loop.

The solution I opted for here is to copy the test code into the
appropriate packages. This leads to some duplication of functionality,
but it effectively breaks the dependency loop and succeeds in
eliminating the test code from our installed library.

Signed-off-by: Chris Lalancette clalancette@openrobotics.org

Still in draft since I need to test on Windows.

[clalancette]

CI:

• Linux
• Linux-aarch64
• macOS
• Windows

[clalancette]

The Windows test failures are the same ones I get with all RViz2 PRs. I'll try to take a look at what is going on there later today. Otherwise, this is ready for review.

[wjwwood]

We shouldn't install test include header files when installing the package; that just ends up on the end user system, and is a non-supported API.

While in principal I agree, in practice I don't really think this is an issue as long as we document what the public API is.

The solution I opted for here is to copy the test code into the appropriate packages.

I'm not a fan of this approach, because keeping these in sync is going to be tough. I'd actually prefer to keep the headers being installed, but in an "obviously not to be used" namespace, rather than copying them around.

Instead, perhaps you could install the headers to a non-standard place, like <prefix>/src/ which we've done in the past. That would prevent people from accidentally using these headers without some special CMake logic, making it far less likely. This has it's own issues when packaging, if you actually use the code at runtime, but since this is for tests only it probably won't cause any issues.

[wjwwood]

Maybe @Martin-Idel has some thoughts about it. I'm sure they ran into this problem and decided to install them at some point. Or maybe I advised them to do it this way, I don't remember.

[clalancette]

I'm not a fan of this approach, because keeping these in sync is going to be tough. I'd actually prefer to keep the headers being installed, but in an "obviously not to be used" namespace, rather than copying them around.

I would argue that we explicitly exclude installing testing type stuff from all other packages. To the extent that we add .ignore and don't release test packages when doing releases. So having these be exposed to the end-user system here seems weird.

Also, while I agree that copying them isn't ideal, I don't think they necessarily need to be kept in sync. As you can see from some of the work I did, the places that they are needed are usually subsets of the overall functionality. So while there is duplication, I would argue that they are logically separate, and can be maintained separately. I agree this isn't totally ideal, but given the overall package structure here, I think the duplication is better than having the test headers and functions in the released binaries.

[wjwwood]

Ok well, that’s fine with me. Like I said I don’t like the duplication but I think your reasoning is ok.

[clalancette]

Ok well, that’s fine with me. Like I said I don’t like the duplication but I think your reasoning is ok.

Great, thanks for the discussion. I'll wait until tomorrow just to give @Martin-Idel another chance to comment, then I'll go ahead and merge.

[clalancette]

All right, I'm going to go ahead and merge this now.