[Cmake-commits] CMake branch, master, updated. v3.15.1-552-g33d9a69

2019-07-31 Thread Kitware Robot
t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index f02ef52..529c0cf 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,7 +1,7 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 15) -set(CMake_VERSION_PATCH 20190731) +set(CMake_VER

Re: [CMake] find_program doesn't use the PATH

2019-07-31 Thread Braden McDaniel
On Wed, 2019-07-31 at 20:32 +0200, Kornel Benko wrote: > The find_program() is searching something like "/usr/bin/NAME". > "NAME" should be a placeholder. > What you had in mind was probably the second form > find_program(GETTEXT_MSGMERGE_EXECUTABLE NAMES msgmerge) > Mark the string "NAMES".

Re: [CMake] find_program doesn't use the PATH

2019-07-31 Thread Kornel Benko
Am Mittwoch, 31. Juli 2019, 12:19:48 CEST schrieb Braden McDaniel: > I was tempted to go ahead and file a bug on this; but it seems so basic > that I figure I must be missing something. > > Per the documentation for find_program: > >If NO_DEFAULT_PATH is not specified, the search process

[CMake] find_program doesn't use the PATH

2019-07-31 Thread Braden McDaniel
I was tempted to go ahead and file a bug on this; but it seems so basic that I figure I must be missing something. Per the documentation for find_program: If NO_DEFAULT_PATH is not specified, the search process is as follows: ⋮ 5. Search the standard system environment variables.

[Cmake-commits] CMake branch, master, updated. v3.15.1-551-g1672d3d

2019-07-31 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 1672d3d5a5a0c5c73a857f5e4592fe998da3ae78 (commit) via

[Cmake-commits] CMake branch, release, updated. v3.15.1-6-g7d98cd0

2019-07-31 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via 7d98cd0442d695df809378dcd5a1eb0c3fb0928a (commit) via

[Cmake-commits] CMake branch, master, updated. v3.15.1-543-g09fe6e6

2019-07-31 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 09fe6e6e9408dde14193f9a358550ac738581cac (commit) via

[Cmake-commits] CMake branch, master, updated. v3.15.1-530-gcb88632

2019-07-31 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via cb8863279033d9dd81d01edcbb5cc8ae1911b06c (commit) via

Re: [cmake-developers] ncurses sub-dir and include path

2019-07-31 Thread Brad King
On 7/30/19 4:57 PM, Christoph Grüninger wrote: > I always end up with /usr/include/ being the CURSES_INCLUDE_PATH. Why is that wrong? As you said it has both `ncurses.h` and `curses.h`. Even though they are symlinks one can still use them to compile. To ignore the symlinks one could configure

Re: [CMake] find_file - strange behavior when using Android toolchain

2019-07-31 Thread Eric Noulard
Le mer. 31 juil. 2019 à 11:19, Stephan Menzel a écrit : > Thank you, Eric and Ugesh, > > Am Mi., 31. Juli 2019 um 09:16 Uhr schrieb Eric Doenges >: > >> My experience has been that find_file and friends behave in unexpected >> ways when you set CMAKE_SYSROOT. In our toolchain files, we set >>

Re: [CMake] find_file - strange behavior when using Android toolchain

2019-07-31 Thread Stephan Menzel
Thank you, Eric and Ugesh, Am Mi., 31. Juli 2019 um 09:16 Uhr schrieb Eric Doenges : > My experience has been that find_file and friends behave in unexpected > ways when you set CMAKE_SYSROOT. In our toolchain files, we set > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) >

Re: [CMake] find_file - strange behavior when using Android toolchain

2019-07-31 Thread ugesh reddy
Hi, Sorry a small correction. There is no such thing as "NO_CMAKE_SYSROOT". find_file(AWSSDK_CORE_HEADER_FILE Aws.h "${AWSSDK_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" "${AWSSDK_DEFAULT_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" NO_CMAKE_FIND_ROOT_PATH *

Re: [CMake] find_file - strange behavior when using Android toolchain

2019-07-31 Thread ugesh reddy
Hi, I also have the same issue with find_file/find_path/find_package when I use the Android NDK and Eric's explanation make sense. One way to solve this find_file(AWSSDK_CORE_HEADER_FILE Aws.h "${AWSSDK_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core"

Re: [CMake] find_file - strange behavior when using Android toolchain

2019-07-31 Thread Eric Doenges
Am 31.07.19 um 08:20 schrieb Stephan Menzel: Hello all, I'm trying to adapt my CMake based toolchain to Android and I'm noticing very strange behavior that I'd like to ask about. My toolchain is C++ based with some dependencies such as Boost, OpenSSL or protobuf. So far it works on a variety

[CMake] find_file - strange behavior when using Android toolchain

2019-07-31 Thread Stephan Menzel
Hello all, I'm trying to adapt my CMake based toolchain to Android and I'm noticing very strange behavior that I'd like to ask about. My toolchain is C++ based with some dependencies such as Boost, OpenSSL or protobuf. So far it works on a variety of platforms such as Windows (MSVC), several