Enhancement #1868
Is build-system-essentials-config.cmake.in correct?
Status: | Rejected | Start date: | 04/30/2014 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | J. Wienke | % Done: | 0% | |
Category: | - | |||
Target version: | - |
Description
When working through the CMake part of the build-system-essentials tutorial yesterday, we had a look at build-system-essentials-config.cmake.in
and noticed two things:
- The filename seems to imply that the package would be used via
find_package(build-system-essentials)
in downstream projects. However, the file exports variables of the formESSENTIALS_*
which does not seem to follow the usual convention of reflecting the package name in the exported variables. Did we miss something? - The project uses RSB but does not re-export variables like
RSB_LIBRARIES
for downstream projects frombuild-system-essentials-config.cmake
. Shouldn't this usually be done?
History
#1 Updated by J. Wienke about 10 years ago
Jan Moringen wrote:
When working through the CMake part of the build-system-essentials tutorial yesterday, we had a look at
build-system-essentials-config.cmake.in
and noticed two things:
- The filename seems to imply that the package would be used via
find_package(build-system-essentials)
in downstream projects. However, the file exports variables of the formESSENTIALS_*
which does not seem to follow the usual convention of reflecting the package name in the exported variables. Did we miss something?
There is no real convention on this. Lot's of CMake find macros do whatever they want. I think the reason here was that otherwise the variables will get unbelievably long.
- The project uses RSB but does not re-export variables like
RSB_LIBRARIES
for downstream projects frombuild-system-essentials-config.cmake
. Shouldn't this usually be done?
The way we expose the downstream projects in rsx is not a standard or convention in any sense. I wouldn't dare to declare this as a convention. We have already seen some issues with that e.g. in the case of projects using multiple components. That was the reason to skip this part for an example project. The usual CMake way is still that downstream projects take care of upstream projects.
#2 Updated by J. Moringen about 10 years ago
- Status changed from Feedback to Rejected
Thanks for the feedback. I guess we can keep the tutorial as it is, then.