When cmake is invoked via a script, an IDE or something like that, it can fail because it is looking for files (headers/libraries) inside the host instead of the SDK.

For example, write this script:

#!/bin/sh
source /your/sdk/environment-setup
cmake ..
make

Then, go into a build directory and run this script.

Depending on which SDK (cross-build or not) and what dependencies are, it can fails because it will try to use you host headers and libraries (i.e. /usr/include).

This is due to the alias of "cmake" done in the SDK, which provide some "default arguments". Aliases are not expanded in not interactive shells (at least using bash, don't know for other shells).

You can add the following line right before sourcing the SDK to make the script work:

shopt -s expand_aliases

This works as a workaround, but you can't do this in every situations. Especially with some IDE in which you can't control how cmake is invoked.

You should not put this line directly in the SDK (like just before the alias is made)

Maybe a better way to do this is to make a script called "cmake" in the SDK, make this script to call the real cmake with those options, and finally make the PATH variable provided by the SDK so that it's use the cmake script instead of the cmake binary. It's a bit dirty but should work in any situation I can think of.