We have a cmake mode on our eclipse plugin but it basically relies on host cmake to function with the cross toolchains in the sdk. Similarly, if you use the cli sdk to do a cmake build. If we include cmake in the sdk, we can avoid using the host version.
added henry so he can comment
This is caused by the 1:1 mapping of host tools used to build an image to nativesdk tools that appear in the SDK. So if your image contains no cmake built packages, you won't get cmake in the SDK. Which in my mind means it's not really an SDK. Provided you use devtool, the eSDK solves this by fetching (and building if not in eSDK sstate mirror) the required tools, as long as they exist in the layers used to build the image. I'm not sure if this "auto-add" is possible with Eclipse integration. This begs the bigger question of whether we make out "SDKs" more usable by adding commonly used host tools that may not be automatically included.
Adding Joshua. The short term adding cmake. Would that be adjusting the autobuilder configuration for making the sdk and esdk? Assigning to Joshua for info :)
(In reply to comment #3) > Adding Joshua. > The short term adding cmake. Would that be adjusting the autobuilder > configuration for making the sdk and esdk? > Assigning to Joshua for info :) I think doing this on the autobuilder would be the wrong approach. If we want to include CMake in the SDK we should probably add nativesdk-cmake to meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb (this then gets included both SDK flavours). nativesdk-cmake is 20MB, which isn't too much of a size impact for an SDK.
It appears the question has been answered.
in master: 7e0985bab68547f946163828a16beab7542fca2e