| Summary: | CMake Toolchain File Has Wrong Module Path | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | aaron_wright |
| Component: | devtools / tool chain | Assignee: | Unassigned <unassigned> |
| Status: | IN PROGRESS REVIEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | aaron_wright, kristi, meta.mr.watcher, meta.watcher, poky.bs.watcher, poky.watcher, randy.macleod, richard.purdie, tgamblin, tim.orling |
| Version: | 2.5.2 | ||
| Target Milestone: | 5.99 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
By using ${STAGING_DATADIR_NATIVE} as the CMAKE_MODULE_PATH, you allow native recipes to add cmake modules to a known directory, which is the desired functionality.
It might be beneficial to actually document the preferred cmake module directory to install modules to too.
Hi, Here is a sub-section of the "Writing a New Recipe" section from the dev-manual - https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#new-recipe-configuring-the-recipe. It mentions Cmake. Also, this sub-section - https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#new-recipe-installing I suspect if we document this we would want to talk about it in the cmake.bbclass section here https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#ref-classes-cmake. Would that be a good assumption? If so, can I get some more explanation for what we need to add? Thanks, Scott (In reply to comment #2) > I suspect if we document this we would want to talk about it in the > cmake.bbclass section here > https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#ref- > classes-cmake. > > Would that be a good assumption? If so, can I get some more explanation for > what we need to add? Yes, documenting it in the cmake.bbclass section would make the most sense. The situation I was running into was that we were creating a recipe that installs cmake modules and wanting to use those modules in a dependent recipe. So we created a cmake-modules-native.bb recipe: > SRC_URI = "file://my-module.cmake" > do_install() { > install ${WORKDIR}/my-module.cmake ${D}${datadir}/cmake/Modules > } > > inherit native We installed it to that directory because that was the directory listed in the toolchain.cmake file generated by cmake.bbclass: > # Use native cmake modules > list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/") In the dependent recipe we had: > DEPENDS += "cmake-modules-native" And in the dependent CMakeLists.txt file we had: > include(my-module) But this didn't work, because, as has been mentioned, CMAKE_MODULE_PATH is not set to the native sysroot for the recipe. Once the bug is fixed in cmake.bbclass, it might be helpful to describe this process of creating recipes that install cmake modules. Perhaps a cmakenative.bbclass should be created instead that could define a variable to use for installing native cmake modules, and which would be assured to correspond to the CMAKE_MODULE_PATH set in the toolchain.cmake file. The documentation for all this could then be added to the cmakenative.bbclass section. I believe your question was answered. Aaron - good detail. I can create the documentation for this. @Paul - I am looking at the cmake.bbclass in poky/master and the issue for setting CMAKE_MODULE_PATH still exists as described by Aaron in his initial comment. Once the fix is in place I can do the documentation. Not sure of the actual implementation ... maybe it creates a new class as suggested... I don't know. We probably should also document the CMAKE_MODULE_PATH variable in the glossary as well. Scott My apologies for not dealing with this properly until now. Looking at it the comment is definitely incorrect (and Richard will be sending a patch to fix that), however in the native case STAGING_DATADIR will be the same as STAGING_DATADIR_NATIVE hence why we haven't seen failures as a result, so I don't think we need to change the value. I suspect we don't need to do too much to the documentation relating to this. We could possibly mention somewhere where you should install cmake modules however this is not a particularly common thing to need to do so it wouldn't need to be mentioned prominently; I'm unsure of the mechanisms off the top of my head but I suspect recipes are getting this right already. Paul, Thanks for looking at this. I am still unsure how to proceed from the documentation end. I see that the comment in line 122 and 123 of the "cmake.bbclass" file (https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cmake.bbclass) has been updated to: # Use our cmake modules list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/") This is presumably Richard's fix? You stated we might mention where you would install CMake Modules. I don't know where or how they would be installed. I need more information if I am going to apply some sort of documentation fix for this bug. Finally, do we want to add the CMAKE_MODULE_PATH variable to the glossary in the YP Reference Manual? Ping Paul... Correct, that was Richard's fix.
CMAKE_MODULE_PATH is not a bitbake variable, so no we would not want to add it to the glossary.
As for where cmake modules should be installed, they should be installed into
${D}${datadir}/cmake/Modules during do_install.
Paul, Can you look at https://www.yoctoproject.org/docs/2.8/mega-manual/mega-manual.html#new-recipe-installing section and tell me if what we say about installing CMake here is adequate? It looks like this is basically saying you don't have to worry about installing CMake. Sort of like what you said in Comment 6. Thanks, Scott Paul? Paul, Can you look at my comment and comment? Thanks, Scott Sorry, I sent you (Scott) an email yesterday in reply, I should have included it here. I'll paste it below:
It's not really about "installing CMake" it's about "installing custom CMake
toolchain files" and it's a rare situation. If anything, all we would need to
say is "If you need to install custom CMake toolchain file(s) supplied by the
application being built, then you would install them to ${D}${datadir}/cmake/
Modules during do_install."
I see the email Paul. Thanks for putting it here in the bug. Scott Paul and Aaron, I added a third note to the note block in the "Installing" section of the "Writing a New Recipe" section (https://yoctoproject.org/docs/3.0/dev-manual/dev-manual.html#new-recipe-installing). It mentions where to install custom CMake toolchain files. Also, in the "Configuring the Recipe" section (https://yoctoproject.org/docs/3.0/dev-manual/dev-manual.html#new-recipe-configuring-the-recipe), I added the same note under the "CMake" bullet item. See https://yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#ref-classes-cmake the "cmake.bbclass" section also for an additional paragraph. Let me know if there are additional changes. Scott Sorry for not looking into this earlier, but I found some time to take a look, and I don't think the issue has been addressed. First off: > however in the native case STAGING_DATADIR will be the same as STAGING_DATADIR_NATIVE hence why we haven't seen failures as a result, so I don't think we need to change the value Is not true in the use case I'm referring to. I'm trying to write a recipe for the target that uses cmake-native to compile. I also have company-wide CMake scripts that help simplify the build, so I want to use them. Thus, cmake-scripts-native is a dependency of my target recipe. This gives: STAGING_DATADIR="/tmp/yocto-tmp/work/ivybridge-32-sel-linux/my-target-recipe/1.0-r0/recipe-sysroot/usr/share" and STAGING_DATADIR_NATIVE="/tmp/yocto-tmp/work/ivybridge-32-sel-linux/my-target-recipe/1.0-r0/recipe-sysroot-native/usr/share" Which are different. Native cmake should not be using scripts from the target (STAGING_DATADIR), but rather, native ones. The comment, "Use native cmake modules," was correct, but the code is wrong. Changing cmake.bbclass to the following fixing the issue: list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR_NATIVE}/cmake/Modules/") > this is not a particularly common thing to need to do I would think that any recipe that wanted to use third party CMake scripts would run into this. We currently work around this bug by including the following in our recipes that inherit from cmake.bbclass:
EXTRA_OECMAKE += "-DCMAKE_MODULE_PATH=${STAGING_DATADIR_NATIVE}/cmake/Modules"
Having it fixed in cmake.bbclass itself would be nice.
Another possibility, if there are existing recipes depending on using modules from the target sysroot, is that both can be added. It still seems odd to me to have a native cmake using target modules though.
FYI, meta-clang has this correct in their cmake-native.bbclass file: https://github.com/kraj/meta-clang/blob/master/classes/cmake-native.bbclass#L47 Paul, Can you sort this out? I won't be able to look at this I'm afraid - moving to unassigned. Bumped to M2, added Michael Opdenacker for what seems to be on a quick read, a documentation component to this defect. Bulk move of 64 bugs to 4.3 M3 after a quick review. If a bug is actually fixed, please add a commit link and resolve it. -- Randy for YP bug team. Moved to M4. I confirm that I see documentation taking the above comments into account: https://docs.yoctoproject.org/ref-manual/classes.html#cmake https://docs.yoctoproject.org/dev-manual/new-recipe.html#installing https://docs.yoctoproject.org/dev-manual/new-recipe.html#configuring-the-recipe Removing myself from CC. Bulk move to 5.0 M1. -- Randy Bulk move of 52 5.0-M1 bugs to M2. Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3. Bulk move of bugs from 5.0-M3 to 5.99. The bugs in this list are all unassigned and are ones that I consider to be nice to do some time but not essential track from milestone to milestone in 5.0 or 5.1. We agreed on this bug handling approach in the YP bug review on Feb 22, 2024. If you disagree, please move back to a 5.[012...]-M* milestone. Aaron, I'm doing bug clean-up so not looking carefully myself. Did this get fixes with: https://git.openembedded.org/openembedded-core/commit/?id=79dc6a23234a34403157dec10d0cdd839ca76b3e ❯ rg CMAKE_MODULE_PATH `fd cmake.bbclass ` meta/classes-recipe/cmake.bbclass 173:list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/") 206:list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR_NATIVE}/cmake/Modules/") |
The CMake toolchain file, as created by meta/classes/cmake.bbclass, sets CMAKE_MODULE_PATH to ${STAGING_DATADIR}/cmake/Modules/. This doesn't agree with the comment above that line that says, "Use native cmake modules", as ${STAGING_DATADIR} isn't the native recipe sysroot. Rather, ${STAGING_DATADIR_NATIVE} should be used instead.