Enhancement #1868

Is build-system-essentials-config.cmake.in correct?

Added by J. Moringen about 10 years ago. Updated about 10 years ago.

Status:RejectedStart date:04/30/2014
Priority:NormalDue 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:

  1. 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 form ESSENTIALS_* which does not seem to follow the usual convention of reflecting the package name in the exported variables. Did we miss something?
  2. The project uses RSB but does not re-export variables like RSB_LIBRARIES for downstream projects from build-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:

  1. 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 form ESSENTIALS_* 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.

  1. The project uses RSB but does not re-export variables like RSB_LIBRARIES for downstream projects from build-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.

Also available in: Atom PDF