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
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
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
Even worse, they seem to acknowledge this problem and created "proxy"
macros for the use by the host OS (code at the bottom)
Is it just me or is this really nasty?
# macro to find packages on the host OS
macro( find_host_package )
set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
set(
On 04/06/2017 04:32 PM, Robert Dailey wrote:
> 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.
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:
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
On Mon, Mar 20, 2017 at 9:20 AM, Brad King 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
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
On Mon, Mar 20, 2017 at 8:40 AM, Brad King wrote:
> On 03/17/2017 05:38 PM, Robert Dailey wrote:
>> find_program(GIT_EXECUTABLE git)
>
> The steps it follows are documented here:
>
> https://cmake.org/cmake/help/v3.8/command/find_program.html
>
> It does include PATH, so
On 03/17/2017 05:38 PM, Robert Dailey wrote:
> find_program(GIT_EXECUTABLE git)
The steps it follows are documented here:
https://cmake.org/cmake/help/v3.8/command/find_program.html
It does include PATH, so it is strange that it is not working.
Just to be sure the environment is as expected,
So I have Git 2.11.1 installed and it's located in E:\Git\cmd\git.exe.
I ticked the option in the installer to add it to path.
I tried using the FindGit module via find_package() to find Git, but
it's not working. So I tried a simpler case:
find_program(GIT_EXECUTABLE git)
However it cannot
12 matches
Mail list logo