I have built SDK I've create CMake project for Yocto File->New...->C Project, Yocto Project SDK CMake Project-> Hello World C CMake Project OK Build project Buildfile generation error occurred.. Build of project failed with the following error: CMake Error: Could not find CMAKE_ROOT !!! CMake has most likely not been installed correctly. Modules directory not found in /home/.../trunk/yocto/poky/build_mcvevk/tmp/sysroots/x86_64-linux/usr/share/cmake-3.5 CMake Error: Error executing cmake::LoadCache(). Aborting. Build stopped.. I go to /home/.../trunk/yocto/poky/build_mcvevk/tmp/sysroots/x86_64-linux/usr/share/ and see cmake-3.6 but not cmake-3.5
Which version of Eclipse (Mars.2, Neon.x) are you using? Which Yocto Project release (jethro, krogoth, morty)? What is your host distro?
Eclipse Neon 2 Yocto morty
Host OS: Ubuntu 16.04 LTS Target machine: Aries MCVEVK (meta-aries)
I've try to build project in terminal: in the directory of project hello_world_cmake/Debug remove all files, except CMakeLists.txt remove all files from Debug source SDK, SDK built in trunk/poky_sdk: $ . /home/.../trunk/poky_sdk/environment-setup-cortexa9hf-neon-poky-linux-gnueabi $ cmake .. $ make and I got correct binary root@mcvevk:~# ./hello_world_cmake Hello World! So, SDK is correct. But in Yocto Project Settings Toolchain Root Location points to directory with Yocto build directory trunk/yocto/poky/build_mcvevk, not SDK.
Is meta-aries available publicly anywhere? I see there is support publicly at http://git.denx.de/?p=eldk.git;a=blob;f=meta-eldk/conf/machine/mcvevk.conf;h=f2993f28f96779a860bf2bc83707c6e7c04dd585;hb=refs/heads/eldk-rel-v5.8
Adding Brian to CC list
https://github.com/ARIES-Embedded/meta-aries
It effects me as well. Eclipse Neon 2 Yocto morty Host OS: Ubuntu 16.10 Target machine: Xilinx Zynq (zc706) (meta-xilinx) The SDK is correct (I successfully built an hello application from a terminal).
Please try one of the options/workarounds outlined in https://wiki.yoctoproject.org/wiki/TipsAndTricks/Cmake,Eclipse,_and_SDKS And comment back if it fixes the issue.
No, it doesn't fix the issue. First I have added cmake into my sdk: There was still error regarding CMAKE_ROOT. Afterwards I have tried Eclipse plugin to use the cmake from the build directory: I have got errors regarding a linker (attachment: CMakeError.log)
Created attachment 3632 [details] Cmake Error log when the Eclipse plugin uese the cmake from the build directory
So, the following steps allowed me to build the Yocto SDK CMake Hello World: 1) add the meta-aries layer from github 2) set the MACHINE="mcvevk" 3) bitbake core-image-sato -c populate_sdk 4) sh ./tmp/deploy/sdk/poky-glibc-x86_64-core-image-sato-cortexa9hf-neon-toolchain-2.2.sh —> installl into /opt/aries/ if the file path is too long here, Eclipse will barf on the the cmake absolute path at invocation time. 5) Windows Preferences -> Yocto Project SDK : Standalone toolchain Toolchain Root -> /opt/aries/ Sysroot -> <browse to > build/tmp/sysroots/mcvevk Architecture -> cortexa9hf-neon-poky-linux-gnueabi No Qemu 6) New Poject -> C -> Yocto Project SDK CMake -> Hello World C Cmake Project” - name it AriesCmake 7) Right click the AriesCmake project and goto Properties->C/C++Build->Settings->Cmake configure->Command and set it to “/opt/aries/sysroots/x86_64-pokysdk-linux/usr/bin/cmake” —> Hit Apply , then Ok 8) right click the Aries Cmake project and click build. — I got a successful build with arm/le binaries… I’m attaching my CMakeOutput.log for comparison. —— The main thing seems to be to make sure to have the sdk installed somewhere with a short enough path (I had a very long path initially and Eclipse failed to find cmake). Then, you *must* set the cmake command to an absolute path in the sdk. If Eclipse gets to use the host cmake, the build will fail.
Created attachment 3633 [details] Successful CmakeOutput.log example This is the CMakeOutput.log from a successful build using a meta-aries sdk via eclipse.
Added explanation of needed steps to work around the fact that eclipse points to /usr/bin/cmake rather than the cmake in the sdk. Not fixing the old code base since a workaround exists.
*** Bug 12364 has been marked as a duplicate of this bug. ***
closing