[cmake-developers] find_program() not using PATH on Windows?

[Robert Dailey]

Yeah I've wanted to use built in support for NDK, but it doesn't work
with Crystax for a number of reasons. Just had no luck with it.
Crystax provides its toolchain file that I have to use.

I'm trying to get away from Crystax, but in the meantime I'm stuck
fixing this obscure issue the same way you did.

On Fri, Apr 7, 2017 at 12:33 PM, Florent Castelli
<florent.castelli at gmail.com> wrote:
> 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.lists at 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.king at 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
>