Bug 12364

Summary: eclipse-poky uses wrong cmake executable and toolchain file
Product: [Yocto Project Subprojects] Eclipse Plugin Reporter: Dennis Menschel <menschel-d>
Component: eclipse-pluginAssignee: brian avery <brian.avery>
Status: RESOLVED DUPLICATE QA Contact: Libertad <libertad.gonzalez.de.la.cruz>
Severity: normal    
Priority: Undecided CC: ioanax.grigoropol, yp.ep.watcher, yp.watcher
Version: 2.4   
Target Milestone: ---   
Hardware: All   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Dennis Menschel 2017-11-18 12:22:19 UTC 
Summary
-------

Trying to compile a simple "Hello World C++ CMake Project" fails because Eclipse uses the wrong cmake executable (native instead of SDK) and the wrong cmake toolchain file (arbitrary hardcoded path instead of correct SDK path).


Preconditions/Environment
-------------------------

Eclipse: Oxygen.1a Release (4.7.1a)
Yocto Project SDK Plugin: 1.4.1.201710162310
SDK: http://downloads.yoctoproject.org/releases/yocto/yocto-2.4/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-armv5e-toolchain-2.4.sh


Triggering Action/Cause
-----------------------

1. Install SDK.
2. Configure Eclipse to use the SDK.
3. Create new "C++ Project", select "Yocto Project SDK CMake Project" and then "Hello World C++ CMake Project".
4. Try to build the project.


Expectation
-----------

Project builds correctly by using the SDK's cmake and the SDK's toolchain file.


Actual Result
-------------

The build fails with the following error if the version of the native cmake happens to differ from the SDK's cmake:

  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
  <OECORE_NATIVE_SYSROOT>/usr/share/cmake-<native cmake version>
  CMake Error: Error executing cmake::LoadCache(). Aborting.
  Build stopped..

If the cmake version happen to be the same, cmake will not find the correct toolchain file and a skeleton toolchain file will be created instead, resulting in a build failure.


Reproducibility
---------------
Always.


Workaround
----------

Set the "Command" entry to the absolute and expanded path of "${OECORE_NATIVE_SYSROOT}/usr/bin/cmake".
Set the "Relative toolchain.cmake path" to "-DCMAKE_TOOLCHAIN_FILE=${OECORE_NATIVE_SYSROOT}/usr/share/cmake/OEToolchainConfig.cmake".


Proposed solution
-----------------

Let eclipse-poky adhere to the SDK as much as possible, i.e.:
- respect the PATH environment variable when searching the cmake executable and
- reuse the information from the cmake alias statement to locate the correct toolchain file.

When the nativesdk-cmake package is included in the SDK, the cmake alias is defined in "${OECORE_NATIVE_SYSROOT}/environment-setup.d/cmake.sh" and looks like follows:

  alias cmake="cmake -DCMAKE_TOOLCHAIN_FILE=$OECORE_NATIVE_SYSROOT/usr/share/cmake/OEToolchainConfig.cmake"
Comment 1 Dennis Menschel 2017-11-20 20:31:01 UTC 
A have to make some corrections about my previous report.

I have repeated the tests today and have found out that the "toolchain.cmake" file in the source directory is not used as an initial input, but is in fact created on the first build invocation of cmake from eclipse. That file already contains information about the cross compiler toolchain even if the wrong cmake executable is selected. The contents of "toolchain.cmake" and "${OECORE_NATIVE_SYSROOT}/usr/share/cmake/OEToolchainConfig.cmake" differ to some extend, but the project can indeed be cross compiled with the generated "toolchain.cmake" file. So I think that I must have made a mistake during my first test and have raised a false alarm. Sorry about that. Nonetheless I find it a bit irritating that eclipse-poky seems to generate the toolchain file itself instead of using the one from the SDK.

Furthermore, concerning the error I've mentioned about the wrong cmake executable being used, I've found out about a duplicate bug report (10919) which has already been closed with a "WONTFIX" status, since a workaround exists. So again, I apologize for the inconvenience.

*** This bug has been marked as a duplicate of bug 10919 ***