Looking further: in cmFindCommon::RerootPaths(), the passed in paths
look correct as far as what PATH shows, and then when this line of
code happens:

const char* rootPath = this->Makefile->GetDefinition("CMAKE_FIND_ROOT_PATH");

it returns a "root path" of:

E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin;E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi;E:/android/ndk/platforms/android-15/arch-arm;E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user;E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share

This is affected by CMAKE_FIND_ROOT_PATH I guess, which the Crystax
NDK toolchain file is mucking with maybe? I do find it bizarre that
directories coming from PATH can be "rerooted" like this, it makes
things very confusing... maybe there is a reason for it, but I'd never
want this personally, and I find it concerning that a toolchain file
can break this for the whole project.

What should I do?

On Thu, Apr 6, 2017 at 3:28 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Brad,
>
> I debugged the issue and so far I'm seeing very weird behavior in the
> cmFindCommon::SearchPaths vector when used from cmFindProgramCommand.
> It goes into FindNormalProgramDirsPerName(), where the wrong "prefix"
> to each path in PATH environment variable is used. Looks like the NDK
> toolchain file is affecting find_program() behavior somehow?
>
> Attached the debug output of the SearchPaths vector to this email. In
> this case, note I'm doing this:
>
> find_program( PYTHON_EXECUTABLE python )
>
> And in the SearchPaths vector, the path to Python is shown as:
>
> E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Python35/
>
> The real location of it (and what is visible in PATH itself) is:
>
> E:/Python35/
>
> On Mon, Mar 20, 2017 at 9:20 AM, Brad King <brad.k...@kitware.com> wrote:
>> On 03/20/2017 10:17 AM, Robert Dailey wrote:
>>> What can I do to help you guys diagnose this problem? I could try
>>> getting a reproducible script for you, but this is so dependent on
>>> environment I'm not sure if it will serve as a good test case.
>>
>> Please build CMake from source with debugging enabled.  Then you
>> can step through the search process.
>>
>> Thanks,
>> -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

Reply via email to