-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't install test header files in rviz_rendering. #564
Conversation
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. |
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.
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 |
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. |
I would argue that we explicitly exclude installing testing type stuff from all other packages. To the extent that we add 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. |
Ok well, that’s fine with me. Like I said I don’t like the duplication but I think your reasoning is ok. |
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>
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
8f38a94
to
79cffa3
Compare
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. |
All right, I'm going to go ahead and merge this now. |
* restore compatibility with older Qt versions (#561) Signed-off-by: Dirk Thomas <dirk-thomas@users.noreply.github.com> * Suppress warnings when building with older Qt versions. (#562) Signed-off-by: Chris Lalancette <clalancette@openrobotics.org> * Don't try to moc generate env_config.hpp file. (#550) This removes one more warning from rviz_common builds. Signed-off-by: Chris Lalancette <clalancette@openrobotics.org> * rewrite hack to avoid CMake warning with assimp 5.0.1 and older, apply cross platform (#565) Signed-off-by: Dirk Thomas <dirk-thomas@users.noreply.github.com> * Use dedicated TransformListener thread (#551) Signed-off-by: ymd-stella <world.applepie@gmail.com> * restore alphabetical include order (#563) Signed-off-by: Karsten Knese <karsten@openrobotics.org> * Don't install test header files in rviz_rendering. (#564) * Don't install test header files in rviz_rendering. 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> Co-authored-by: Dirk Thomas <dirk-thomas@users.noreply.github.com> Co-authored-by: Chris Lalancette <clalancette@openrobotics.org> Co-authored-by: ymd-stella <7959916+ymd-stella@users.noreply.github.com> Co-authored-by: Karsten Knese <Karsten1987@users.noreply.github.com>
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.