USE_SCOPED_HEADER_INSTALL_DIR path issues
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cmake, cpp
- Domain
- build-system
Research direction
Start by reproducing the downstream compilation failure with the described st_ptz_control and st_flir packages, then inspect their CMakeLists.txt files and the generated st_ptz_control_params.hpp include and install paths. Compare the installed header layout with the include path used by ptz.hpp; done means a downstream package can include onvif_ptz.hpp without a missing-header error or deprecation warning.
Written by the indexing model from the issue text.
Description
Running ROS2 Jazzy on Ubuntu 24.04.3
We have started migrating to the new include path location by adding USE_SCOPED_HEADER_INSTALL_DIR to our ament_auto_package() calls in our CMakeLists.txt files (https://github.com/ament/ament_cmake/pull/577). This creates a problem when the generated params.hpp header is included in a public installed header that is then included in a downstream package.
Source
Given this package
src/camera/st_ptz_control/include/st/camera/ptz/onvif_ptz.hpp
src/camera/st_ptz_control/include/st/camera/ptz/ptz.hpp
where onvif_ptz.hpp has the line
#include "st/camera/ptz/ptz.hpp"
where ptz.hpp has the line
#include <st_ptz_control/st_ptz_control_params.hpp>
and its CMakeLists (cruft removed):
generate_parameter_library(
st_ptz_control_params
src/params.yaml
)
ament_auto_add_library(
st_ptz_control_component SHARED
src/ptz.cpp
)
target_link_libraries(
st_ptz_control_component
st_ptz_control_params)
ament_auto_package(USE_SCOPED_HEADER_INSTALL_DIR)
This produces installed headers:
/opt/st/core/st_ptz_control
|-- include
| `-- st_ptz_control
| |-- st
| | `-- camera
| | `-- ptz
| | |-- commands.hpp -> /workspace/STcore/core/src/camera/st_ptz_control/include/st/camera/ptz/commands.hpp
| | |-- onvif_ptz.hpp -> /workspace/STcore/core/src/camera/st_ptz_control/include/st/camera/ptz/onvif_ptz.hpp
| | |-- ptz.hpp -> /workspace/STcore/core/src/camera/st_ptz_control/include/st/camera/ptz/ptz.hpp
| | `-- visibility_control.hpp -> /workspace/STcore/core/src/camera/st_ptz_control/include/st/camera/ptz/visibility_control.hpp
| `-- st_ptz_control_params.hpp -> /workspace/STcore/core/build/st_ptz_control/include/st_ptz_control/st_ptz_control_params.hpp
This package is used by a downstream package with the header
src/camera/st_flir/src/flir.hpp
which has the line
#include "st/camera/ptz/onvif_ptz.hpp"
and its package.xml has
<depend>st_ptz_control</depend>
Issues
As-written, this generates a compilation error in st_flir:
--- stderr: st_flir
In file included from /opt/st/core/st_ptz_control/include/st_ptz_control/st/camera/ptz/onvif_ptz.hpp:3,
from /workspace/STcore/core/src/camera/st_flir/src/flir.hpp:3,
from /workspace/STcore/core/src/camera/st_flir/src/flir.cpp:1:
/opt/st/core/st_ptz_control/include/st_ptz_control/st/camera/ptz/ptz.hpp:6:10: fatal error: st_ptz_control/st_ptz_control_params.hpp: No such file or directory
6 | #include <st_ptz_control/st_ptz_control_params.hpp>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
gmake[2]: *** [CMakeFiles/st_flir_component.dir/build.make:76: CMakeFiles/st_flir_component.dir/src/flir.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:139: CMakeFiles/st_flir_component.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
---
Failed <<< st_flir [0.12s, exited with code 2]
If I modify the include in onvif_ptz.hpp to be just #include <st_ptz_control_params.hpp> then I get a deprecation warning:
--- stderr: st_ptz_control
In file included from /workspace/STcore/core/src/camera/st_ptz_control/include/st/camera/ptz/ptz.hpp:5,
from /workspace/STcore/core/src/camera/st_ptz_control/src/ptz.cpp:1:
/workspace/STcore/core/build/st_ptz_control/include/st_ptz_control_params.hpp:1:137: note: ‘#pragma message: #include "st_ptz_control_params.hpp" is deprecated. Use #include <st_ptz_control/st_ptz_control_params.hpp> instead.’
1 | #pragma message("#include \"st_ptz_control_params.hpp\" is deprecated. Use #include <st_ptz_control/st_ptz_control_params.hpp> instead.")
Which, if I follow the instructions in the deprecation warning, it appears to be a valid path based on the installed header structure.
- Dominant language
- Python
- Stars
- 385
- Forks
- 81
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PickNikRobotics/generate_parameter_library
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
PickNikRobotics/generate_parameter_library#392 · 2 comments ·
-
GCC 15 emits -Wfree-nonheap-object for generated string one_of validationPossibly taken @tylerjw claimed this 17 days ago. Open
PickNikRobotics/generate_parameter_library#389 · 1 comment · 1 assignee ·
-
Feature request: math in the yamlPossibly taken @tylerjw claimed this 17 days ago. Open
PickNikRobotics/generate_parameter_library#381 · 2 comments · 1 reaction · 1 assignee ·
-
Validator reference (bounds<>/element_bounds<> etc.) is hard to find inside the READMEPossibly taken @tylerjw claimed this 17 days ago. Open
Difficulty 5/5 Over a week Newbie friendliness 25/100
PickNikRobotics/generate_parameter_library#377 · 1 comment ·
All issues in PickNikRobotics/generate_parameter_library
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
aws-samples/sample-per-model-bedrock#243 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
FuRongJun-1999/dsh-memory#404 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
bug frontend
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
PennyLaneAI/catalyst#3337 ·
Maintainers usually reply within 1 day
-
Workflow.schedule stops when a cron deadline passes before sleepPossibly taken @HuaTNA claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day