What you mentioned is a classic problem of that famous Android toolchain. When 
I used it, I just patched it and set the CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to 
NEVER directly, and removed some harmful pieces in there (like that find macro 
and some other bug fix for macOS builds, libc++ and recent NDK support…).

Have you considered switching to the upstream support in either CMake or the 
one provided by Google with Gradle?
You can probably just upgrade to the first one and get rid of similar issues by 
just tweaking the CMake command line.

For the other issues you mentioned of compiling for multiple architectures, the 
Gradle CMake plugin should handle that and build all the ones you specify.
That one will be a bit more complicated to implement as you need to transition 
from Ant to Gradle, but I remember the ant tooling being deprecated now, so it 
should improve the situation a little bit.

/Florent

> On 7 Apr 2017, at 14:32, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> 
> Thanks for the feedback Brad, as always. Really appreciate your
> continued help. Sorry for continuing the discussion on the dev list.
> 
> To close out the discussion just wanted to share (for others that may
> run into this issue) that I went ahead and just added this line to my
> root CMakeLists.txt file:
> 
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> 
> This at least disables the root path for programs. I didn't add it to
> the toolchain itself since I don't know the impact of doing it, nor do
> I really care to support it. I'm slowly trying to move away from
> Crystax at my workplace in favor of official NDK since that has built
> in support in CMake and also is run a little better (Crystax has been
> a fat mess to use; we originally only chose to use it for the prebuilt
> libraries, but not worth it)
> 
> Thanks again!!
> 
> On Fri, Apr 7, 2017 at 7:16 AM, Brad King <brad.k...@kitware.com> wrote:
>> On 04/06/2017 04:43 PM, Robert Dailey wrote:
>>> Even worse, they seem to acknowledge this problem and created "proxy"
>>> macros for the use by the host OS (code at the bottom)
>> 
>> Interesting.  That approach depends on all projects using their
>> macros instead of the normal `find_package`, requiring explicit
>> porting to use their toolchain file.
>> 
>> Typically toolchain files should do this:
>> 
>> ```
>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>> ```
>> 
>> so that packages for the target platform are found in the
>> re-rooted locations but programs are found on the host.
>> 
>> -Brad
>> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Reply via email to