Re: [CMake] cmp0065

Hi, On Tuesday 05 July 2016 23:46:16 J Decker wrote: > https://cmake.org/cmake/help/v3.4/policy/CMP0065.html > while I like the idea it suggests, I don't use the flags for -rdynamic so > this is meaningless to me I'm not sure I understood you correctly, but if the policy is meaningless to you,

Re: [CMake] Confusion over INTERFACE vs STATIC|SHARED IMPORTED vs INTERFACE IMPORTED

There is one difference that I thought of immediately, and I tested it - an INTERFACE target can be installed/exported, but an INTERFACE IMPORTED target cannot be installed/exported because CMake considers it to not be in the build/source directory. I'm sure there are other internal differences

[CMake] Disable removing generated file

Hello guys!How to disable removing generated file with clean target?My custom command generate or update file. -- 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

Re: [CMake] ImageMagick Not Found with CMake

On 07/05/2016 03:59 PM, Gonzalo wrote: > El 05/07/16 a las 15:05, Richard Kralik escribió: >> Why can FindImageMagick not find convert and mogrify? > My guess. Because they are in /usr/local/bin and cmake does not check that. > > Call cmake with your standard options plus: > >

[CMake] How to disable the CPack preinstall build?

Hello All, I'm looking for some CPack (3.5.2) wrangling assistance... I have CMake automatically generating a unique ID on every build. This ID is compiled into several components of my project and I want the same value to appear in my package file name. I do this by inserting it into a CPack

Re: [CMake] How to disable the CPack preinstall build?

Good chance CMAKE_BUILD_WITH_INSTALL_RPATH may be what you are looking for. There's also always the option of just running cpack directly rather than "make package" (not sure if that will avoid the part of the

Re: [CMake] cmp0065

Hi, On Wednesday 06 July 2016 08:43:44 you wrote: > > #if defined(WIN32) > > #endif > > not WIN32 that way... as in add_executable( something WIN32 ... ) (or not > WIN32) I'm not sure I can follow. I thought you want to have compile time definitions like "-DSOMETHING" for GCC or "/DSOMETHING"

[CMake] Fwd: cmp0065

(probably breaks thread coherance; misreplied) -- Forwarded message -- From: J Decker Date: Wed, Jul 6, 2016 at 8:43 AM Subject: Re: [CMake] cmp0065 To: Johannes Zarl-Zierl On Wed, Jul 6, 2016 at 2:52 AM, Johannes Zarl-Zierl <

Re: [CMake] cmp0065

M:/tmp/cmake_cmp0065/CMakeLists.txt(1): cmake_minimum_required(VERSION 3.0 ) M:/tmp/cmake_cmp0065/CMakeLists.txt(2): project(cmake-test ) M:/tmp/cmake_cmp0065/CMakeLists.txt(3): add_executable(myExe main.c ) M:/tmp/cmake_cmp0065/CMakeLists.txt(4): target_compile_definitions(myExe PRIVATE

[CMake] cmp0065

Seems like you ought to be able to avoid this warning just by setting ENABLE_EXPORTS to 0 or 1 ... If you're going to require 3.0, then use 3.0. If you're going to use 3.5, then add the property to squelch the warning and get the behavior you want. D On Wednesday, July 6, 2016, J Decker

Re: [CMake] cmp0065

Seems like you ought to be able to avoid this warning just by setting ENABLE_EXPORTS to 0 or 1 ... If you're going to require 3.0, then use 3.0. If you're going to use 3.5, then add the property to squelch the warning and get the behavior you want. D On Wednesday, July 6, 2016, J Decker

Re: [CMake] CTest - how to structure tests for different test jobs with a shared build-dir

Hi list, On Wed, 6 Jul 2016 10:19:05 +0200 Patrick Boettcher wrote: > I have several options at hand: > > - I could install the tests into the test-job-workspace (not sure if > this will really work with ctest) > - I could copy the build-dir (what about the

[CMake] [Visual Studio] Universal Windows Platform projects

Hello all, I've been trying to identify the correct variables to set to create a UWP project using VS2015, and the projects generated are missing a few critical tags. I'm using CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0. This correctly identifies and sets the target platform

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-333-g73f480b

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 73f480b0ad6a9fed1dcadab7ff2b1afb6547941a (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-335-g0bcb9ef

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 0bcb9efdff2feb0fcbcd8f6982bab956c105c52d (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-337-g7c8c07d

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 7c8c07d03c26304ea023b3d7ce828996088d49bd (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-341-gf2c1900

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 f2c1900a71a0717b96a0b263186767658de72baa (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-339-g7e53e6c

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 7e53e6c9cc1b8266ccc06aca8184612256a3669d (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-718-g6682db6

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, next has been updated via 6682db6c2e7f8ebcd0e3448b93d2786d250104f0 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-331-gf45befe

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 f45befed3af7f24cf8aae1a29d3475ad6ae0b161 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-329-g50adbfc

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 50adbfcacb27ea656f51a699af78828aad59bde6 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-318-g0219743

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 0219743a01c1c89c5b67d18c1094731c4b609ffa (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-320-g8df2e68

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 8df2e68614b0de60f5d5fcfba63012903815adef (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-316-g06af626

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 06af626ef2ffb6a8c6b4b91bd372849798426b76 (commit) via

[cmake-developers] [PATCH v3 5/7] For consoles output on Windows use our own std::streambuf

Currently Microsoft's C++ libraries implementation of std::cout/cerr can't output Unicode characters but only ASCII or ANSI if locale is set so we implement and use our own ConsoleBuf which can output Unicode characters to console and it doesn't matter what locale or console's codepage is set. ---

[cmake-developers] [PATCH v3 1/7] On Windows use correct encoding for SystemTools::GetEnv

On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv) instead and encode that. Also add SystemTools::HasEnv function. --- Source/kwsys/SystemTools.cxx| 56

[cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream

std::basic_filebuf::open(const wchar_t *) isn't part of C++ standard and it's only present for MSVC but it's not present in libstdc++ (MinGW) so we implement this functionality using GNU stdio_filebuf extension and _wfopen function. --- Source/kwsys/FStream.hxx.in | 117

[cmake-developers] [PATCH v3 2/7] Deprecate const char* SystemTools::GetEnv function

On Windows this function returns environment variable encoded in ANSI codepage which might not match internally used encoding. --- Source/kwsys/SystemTools.hxx.in | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/Source/kwsys/SystemTools.hxx.in

[cmake-developers] [PATCH v3 6/7] Use Windows version of Directory::Load for MinGW too

Otherwise it would use POSIX functions which works only for ASCII paths. --- Source/kwsys/Directory.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Source/kwsys/Directory.cxx b/Source/kwsys/Directory.cxx index c549792..659c559 100644 --- a/Source/kwsys/Directory.cxx +++

[cmake-developers] [PATCH v3 3/7] Use SystemTools::GetEnv and HasEnv functions

--- Source/CPack/cmCPackGenerator.cxx | 8 +++--- Source/CTest/cmCTestCoverageHandler.cxx | 12 - Source/CTest/cmCTestCurl.cxx| 27 ++-- Source/CTest/cmCTestMultiProcessHandler.cxx | 8 +++--- Source/cmBuildCommand.cxx | 25

[cmake-developers] [PATCH v3 4/7] For Windows encode process output to internally used encoding

Typically Windows applications (eg. MSVC compiler) use current console's codepage for output to pipes so we need to encode that to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE). --- Source/kwsys/CMakeLists.txt | 2 ++ Source/kwsys/ProcessWin32.c | 25 - 2

Re: [cmake-developers] [PATCH v3 5/7] For consoles output on Windows use our own std::streambuf

From what I remember, WriteConsoleW doesn't support redirection to a file or pipe.  I don't see an alternative in the patch for the case where stdout is not attached to the console. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] [PATCH v3 3/7] Use SystemTools::GetEnv and HasEnv functions

On 07/06/2016 10:12 PM, Dāvis Mosāns wrote: > --- a/Source/kwsys/SystemInformation.cxx > +++ b/Source/kwsys/SystemInformation.cxx > @@ -219,6 +219,8 @@ typedef struct rlimit ResourceLimitType; > # define USE_CPUID 0 > #endif > > +#include > + > #if USE_CPUID > > #define

Re: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream

On 07/06/2016 10:12 PM, Dāvis Mosāns wrote: > --- a/Source/kwsys/FStream.hxx.in > +++ b/Source/kwsys/FStream.hxx.in > @@ -14,33 +14,76 @@ > > #include <@KWSYS_NAMESPACE@/Encoding.hxx> > #include > +#if defined(_WIN32) && !defined(_MSC_VER) > +#include > +#endif > > namespace

Re: [cmake-developers] [PATCH v3 5/7] For consoles output on Windows use our own std::streambuf

2016-07-07 1:36 GMT+03:00 Mike Gelfand : > On 07/07/2016 12:42 AM, clin...@elemtech.com wrote: >> From what I remember, WriteConsoleW doesn't support redirection to a >> file or pipe. I don't see an alternative in the patch for the case >> where stdout is not attached to the

Re: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream

On 07/07/2016 03:33 AM, Dāvis Mosāns wrote: > 2016-07-07 1:22 GMT+03:00 Mike Gelfand : >>> @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@ >>> [snip] >>>private: >>> internal_buffer_type* buf_; >>> +#if !defined(_MSC_VER) >>> +FILE *file_ = 0; >>> +#endif >>> };

Re: [cmake-developers] [PATCH v3 5/7] For consoles output on Windows use our own std::streambuf

On 07/07/2016 12:42 AM, clin...@elemtech.com wrote: > From what I remember, WriteConsoleW doesn't support redirection to a > file or pipe. I don't see an alternative in the patch for the case > where stdout is not attached to the console. The SO thread I pointed at actually contained a check for

Re: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream

2016-07-07 3:51 GMT+03:00 Mike Gelfand : > On 07/07/2016 03:33 AM, Dāvis Mosāns wrote: >> 2016-07-07 1:22 GMT+03:00 Mike Gelfand : @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@ [snip] private: internal_buffer_type* buf_;

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-347-g5553aab

_VERSION_MINOR 6) -set(CMake_VERSION_PATCH 20160706) +set(CMake_VERSION_PATCH 20160707) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-727-ga773216

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, next has been updated via a7732165b12033c54d93d3a98b5e473ce4f2711c (commit) via

Re: [cmake-developers] ExternalProject default downloaded file name

On 07/05/2016 05:14 PM, Ruslan Baratov wrote: > if it will work in most cases then why not? Most users will not > even notice this. Okay. The changes for the new pattern are now in `master` and are worthwhile regardless of having a default filename fallback because they help extract a more

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-732-gd845baf

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, next has been updated via d845baf36b440bcb1276585637921d2babab3ba7 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-346-gafa26a4

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 afa26a43fd5d6f50fa8dc776677a5d10df6fbf19 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-730-gf23c91e

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, next has been updated via f23c91e0ede8de852c9d63d5ae8d878294712a79 (commit) via

[Cmake-commits] CMake branch, release, updated. v3.6.0-rc4-9-g6643fe1

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 6643fe1481338a751729b2de5db1954f1824c15c (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-724-g79384df

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, next has been updated via 79384df8ec5f234d3a08da089393f12a6518218b (commit) via

Re: [cmake-developers] Green Hills MULTI Generator Recommendations

> I am interested in using CMake with Green Hills MULTI Great! > 2. Is there a way in a toolchain file or on the command line to specify the > directory where CMake should look for the compiler executables? Take a look at