12760 2018-05-24 21:34:33 +0000 CMake Toolchain File Has Wrong Module Path 2026-03-11 15:09:45 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 2.5.2 x86 Multiple IN PROGRESS REVIEW Medium+ normal 5.99 1 aaron_wright unassigned aaron_wright kristi meta.mr.watcher meta.watcher poky.bs.watcher poky.watcher randy.macleod richard.purdie tgamblin tim.orling --- --- Yes (doc changes required) oldest_to_newest 80638 0 aaron_wright 2018-05-24 21:34:33 +0000 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. 80670 1 aaron_wright 2018-05-30 16:56:42 +0000 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. 80680 2 srifenbark 2018-05-31 23:21:46 +0000 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 80681 3 aaron_wright 2018-05-31 23:47:40 +0000 (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. 80685 4 sjolley.yp.pm 2018-06-01 16:18:35 +0000 I believe your question was answered. 82365 5 srifenbark 2018-11-29 17:00:04 +0000 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 84259 6 bluelightning 2019-06-20 10:19:54 +0000 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. 84304 7 srifenbark 2019-06-21 18:06:01 +0000 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? 84329 8 randy.macleod 2019-06-27 14:50:32 +0000 Ping Paul... 84387 9 bluelightning 2019-07-08 21:44:55 +0000 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. 84395 10 srifenbark 2019-07-09 23:18:40 +0000 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 84730 11 randy.macleod 2019-08-22 14:59:52 +0000 Paul? 85341 12 srifenbark 2019-10-14 14:43:39 +0000 Paul, Can you look at my comment and comment? Thanks, Scott 85349 13 bluelightning 2019-10-16 02:18:22 +0000 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." 85386 14 srifenbark 2019-10-17 17:33:23 +0000 I see the email Paul. Thanks for putting it here in the bug. Scott 85389 15 srifenbark 2019-10-17 19:07:48 +0000 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 85396 16 aaron_wright 2019-10-18 19:58:03 +0000 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. 85397 17 aaron_wright 2019-10-18 20:10:45 +0000 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. 85425 18 aaron_wright 2019-10-23 18:53:28 +0000 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 87032 19 randy.macleod 2020-04-16 07:41:01 +0000 Paul, Can you sort this out? 88670 20 bluelightning 2020-11-23 20:49:44 +0000 I won't be able to look at this I'm afraid - moving to unassigned. 92196 21 randy.macleod 2021-12-21 00:54:22 +0000 Bumped to M2, added Michael Opdenacker for what seems to be on a quick read, a documentation component to this defect. 96100 22 randy.macleod 2023-07-26 21:22:06 +0000 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. 96435 23 tgamblin 2023-09-14 15:44:29 +0000 Moved to M4. 96502 24 michael.opdenacker 2023-09-14 19:05:50 +0000 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. 97053 25 randy.macleod 2023-10-30 15:29:08 +0000 Bulk move to 5.0 M1. -- Randy 97681 26 randy.macleod 2023-12-21 23:28:30 +0000 Bulk move of 52 5.0-M1 bugs to M2. 97985 27 randy.macleod 2024-01-25 14:28:43 +0000 Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3. 98286 28 randy.macleod 2024-02-22 19:53:19 +0000 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. 104580 29 randy.macleod 2026-03-11 15:09:45 +0000 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/")