[cmake-developers] [CMake 0014754]: fixing up bundles fails in short windows path names

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14754 == Reported By:Andreas Pakulat Assigned To:

[cmake-developers] visual-studio-preprocessor-undefine fix for /U problems

I just pushed a tiny topic branch that fixes problems in the Visual Studio generators where the generators will squash the use of /U in compile flags. The change allows /U to go through correctly to the compiler command line. The topic is visual-studio-preprocessor-undefine. SteveW

[cmake-developers] Objective-C support

I just pushed a small topic branch to stage the introduces support for Objective-C as a ‘supported’ language with a separate identity from C/CXX. The topic name is ‘objective-c-support.’ SteveW signature.asc Description: Message signed with OpenPGP using GPGMail -- Powered by

Re: [CMake] Run clean before automatically re-running cmake?

You are correct that I would prefer that behavior, however I'd prefer to go for safety (and do a full clean) until that more advanced logic can be implemented... I am in fact using ninja, so hopefully that feature may come down the pipe soon :-) If you want a full build, why don't you just

[CMake] Path vs. name preference during search.

When I search for a given library, specifying multiple possible names and multiple hints for paths... FIND_LIBRARY( FINDME_LIB NAMES name1 name2 name3 HINTS path1 path2 path3 DOC Library to find) CMake seems to have a preference for name1, and it first searches all HINTS

[CMake] CMake/CPack /w BundleUtilities on Windows with NSIS fails

Hi, I have a CMake script that runs on Windows with MinGW Makefiles that builds the install target OK. It is a Qt GUI application and uses BundleUtilities::fixup_bundle to pull in and link/rpath prerequisites. When I build the package target with an NSIS packager it looks like the

Re: [CMake] Path vs. name preference during search.

Hi Rob, Do address the use case you described, I usually explicitly set the path the library when built as an external project and rely only on the find_* command for the use_system case. See

Re: [CMake] Path vs. name preference during search.

Jc, That is an approach I have thought about. I even think I have looked at Slicer for how you work your CMake system. I prefer to use project-supplied FindLIB.cmake (or a slightly modified version thereof) because some of them do more than just setting LIBRARY, INCLUDE_DIR, and FOUND

Re: [CMake] CMake/CPack /w BundleUtilities on Windows with NSIS fails

On 13/02/2014 18:10, Bill Somerville wrote: Hi, I have a CMake script that runs on Windows with MinGW Makefiles that builds the install target OK. It is a Qt GUI application and uses BundleUtilities::fixup_bundle to pull in and link/rpath prerequisites. When I build the package target with

Re: [CMake] CMake/CPack /w BundleUtilities on Windows with NSIS fails

On 2/13/2014 2:23 PM, Bill Somerville wrote: I would really like to know why it is going wrong with dumpbin in package generation because using objtool is too slow! Sounds like a PATH issue. Try getting dumpbin to work from the command line that you are using. -Bill -- Powered by

Re: [CMake] CMake/CPack /w BundleUtilities on Windows with NSIS fails

On 13/02/2014 19:44, Bill Hoffman wrote: HI Bill, On 2/13/2014 2:23 PM, Bill Somerville wrote: I would really like to know why it is going wrong with dumpbin in package generation because using objtool is too slow! Sounds like a PATH issue. Try getting dumpbin to work from the command line

[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7711-g2c5ceb3

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

[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7713-geb3e908

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

[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7715-gf251a27

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

[Cmake-commits] CMake branch, master, updated. v2.8.12.2-1437-g79bb8cf

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

[Cmake-commits] CMake branch, master, updated. v2.8.12.2-1435-gaa23381

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

[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7718-g49b96a7

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

[Cmake-commits] CMake branch, master, updated. v2.8.12.2-1438-g945a66a

Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index c3a319a..09075b1 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 12) -set(CMake_VERSION_TWEAK 20140213