Ah! In that case there are two main ways, one is fully in-cmake but is a pain and not generally recommended due to the pain, the other way is to use CMake’s ExternalProject built-in system, which was added in 2.6 or 2.8 or so. Basically just have multiple projects, like tools that should always be built for the host OS you can put in one project, things that should build for potentially multiple things in another. From your main project just ExternalProject_Add and pass in the arguments you need. So for example, one way it can be set up is to have your ‘main’ project (which really really really badly should be a CMakeLists.txt in the root of the git tree, even if it just starts immediately going to a subdirectory like Source) be the platform that you want to build to, the TARGET platform. Have it ExternalProject_Add the tools that need to be run on the local HOST system, when it builds you can then ExternalProject_Get_Property to get the variables from that external project, such as the location of the binary to use in a build step elsewhere say for code generation or atlas generation or whatever you need, or bring in include files and the library path to link to (well not that part for cross-compiling obviously). Once you bring in the variables just name them whatever you want and use them as normal, as if they are just in your project. With ExternalProject Cross-Compiling with host-only tools became much easier. 
It ‘should’ be completely possible to do an entire and complete CMake build system nowadays without an overuse of Macros either, such as the output ‘Bin’ directory really should not exist, the resultant binaries and Data directories should be in the build directory for if people want to test, and the Install commands should let the user install it where-ever they wish. Then with proper CTest and CPack support you could make travis just fly and make installers that are far easier to include in other projects. Plus if the CMake build follows proper standards (such as generating the definition file that points to the local library, data, configuration vars, etc… of the build) then bringing in Urho3D into an external project without needing to pre-compile or anything would be utterly simple. It would remove all the non-standard steps in the build process for usual systems and for generating the android bits then something like https://code.google.com/p/android-cmake/ would simplify that work as well since android is so… javaish.
At that point then out-of-source builds would be fully supported and Urho3D would fit naturally in to any normal CMake ecosystem, and in fact if done properly then they could just ExternalProject_Add in Urho3D in to their project to have their project auto git clone it, compile, and use the resultant file. A few helpers for android would still be useful to have of course so a custom cmake command can do the android build for the entire of the project.
