[Cmake-commits] CMake branch, master, updated. v3.11.0-rc2-118-gdbfdb90

[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  dbfdb90430c7a55b9b6589d30df16ca2aaad52b8 (commit)
  from  dc13ed1f84601a8d9710cc2a8c76d0331be561b8 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dbfdb90430c7a55b9b6589d30df16ca2aaad52b8
commit dbfdb90430c7a55b9b6589d30df16ca2aaad52b8
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sat Mar 3 00:01:12 2018 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sat Mar 3 00:01:12 2018 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 6fe9698..7e9ba0d 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 11)
-set(CMake_VERSION_PATCH 20180302)
+set(CMake_VERSION_PATCH 20180303)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Swift executables with MACOSX_BUNDLE fail to find libswiftCore.dylib

[Lucas Šoltić]

You miss a runtime search path when linking your executable. And this is what 
you achieved with install_name_tool with an additional step.

To avoid this additional step, see 
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html
or
https://stackoverflow.com/questions/42613881/adding-run-time-shared-library-search-path-to-executable-at-compile-time-clang

By the way this is not related to Swift at all.

Lucas

> Le 2 mars 2018 à 20:12, Harry Mallon  a écrit :
> 
> Hello all,
>  
> When making a pure Swift bundle Xcode automatically copies 
> `libswiftCore.dylib` as follows.
>  
> ```
> ./Tests/SwiftOnly/Debug/SwiftOnly.app
> └── Contents
> ├── Frameworks
> │   └── libswiftCore.dylib
> ├── Info.plist
> ├── MacOS
> │   └── SwiftOnly
> ├── PkgInfo
> └── Resources
> └── libswiftRemoteMirror.dylib
> ```
> When I try to run the output I get a dynamic linking error. I can reproduce 
> this by adding MACOSX_BUNDLE to `./Tests/SwiftOnly/CMakeLists.txt` (in the 
> CMake source tree) in `add_executable` and trying to run the result.
>  
> ```
> % ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly
> dyld: Library not loaded: @rpath/libswiftCore.dylib
>   Referenced from: 
> .../Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly
>   Reason: image not found
> zsh: abort  ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly
> ```
>  
> It seems that the rpath should be set to `@loader_path/../Frameworks`. I am 
> not a Swift maestro so not exactly sure on the details of how this works. 
> After running `install_name_tool -add_rpath "@loader_path/../Frameworks" 
> ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly` it runs fine.
>  
> Does anyone have any idea what to do? Is it a missing CMake Swift feature? We 
> are currently working around it by manually adding the rpath with a cmake 
> step.
>  
> Harry
> Harry Mallon
> Senior Software Engineer
> 
> 
> 
> T +44 203 7000 989 
> 60 Poland Street | London | England | W1F 7NT 
> 
> Three Billboards  Blade Runner 2049I, Tonya
> 
> -- 
> 
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] failure to build Cmake to / against non-standard directory under Linux

[Ben Sferrazza]

I was able to get 3.9.6 to compile setting CMAKE_PREFIX_PATH to the same
path that I pass .bootstrap with --prefix. I also had to patch
the Modules/Compiler/GNU.cmake file to use -idirafter rather than -isystem
as the latter leads to issues with #include_next.

I'm still perplexed why 3.10.2 thinks doesn't think my compiler, GCC 7.3.0,
is C++11 compliant. The only thing I can think of is that I am using a
somewhat older version of Glibc, 2.19, as that is the newest version
compatible with the host's kernel of 2.6.18. However, that glibc was
released in 2014, so I would think that wouldn't be the case.

On Fri, Mar 2, 2018 at 10:04 AM, Ben Sferrazza 
wrote:

> I have a completely insulated boostrapped toolchain+binaries setup
> (located under /home/tools), following much of the Linux From Scratch book,
> that has been able to build everything that I throw at it. Most things
> just work with a simple --prefix option, as I have also edited the GCC
> specs file to include my /home/tools/include directory (using -isystem) and
> link against my /home/tools/lib directory (also with an rpath set, so that
> all binaries I build are complete insulated from the host libraries). The
> lone exception to this is Cmake. It appears to have a lot of hardcoded
> paths in its build environment to standard /usr/* directories.
>
> I first got wind that something was awry when Cmake 3.10.2 claimed my
> compiler, GCC 7.3.0, isn't C++11 compliant. Clearly this isn't the case,
> given that it's the latest release. So I then tried building Cmake 3.9.6,
> which doesn't require C++11, and it was finding zlib and other libraries
> under /usr/lib as opposed to my /home/tools/lib. I don't even have
> LD_LIBRARY_PATH set, as I use rpath in the specs file like I mentioned. Can
> anyone provide any help into how I can get Cmake to build against
> non-standard include and library locations?
>
> Thank you,
> Ben
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Swift executables with MACOSX_BUNDLE fail to find libswiftCore.dylib

[Harry Mallon]

Hello all,

When making a pure Swift bundle Xcode automatically copies `libswiftCore.dylib` 
as follows.

```
./Tests/SwiftOnly/Debug/SwiftOnly.app
└── Contents
├── Frameworks
│   └── libswiftCore.dylib
├── Info.plist
├── MacOS
│   └── SwiftOnly
├── PkgInfo
└── Resources
└── libswiftRemoteMirror.dylib
```
When I try to run the output I get a dynamic linking error. I can reproduce 
this by adding MACOSX_BUNDLE to `./Tests/SwiftOnly/CMakeLists.txt` (in the 
CMake source tree) in `add_executable` and trying to run the result.

```
% ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly
dyld: Library not loaded: @rpath/libswiftCore.dylib
  Referenced from: 
.../Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly
  Reason: image not found
zsh: abort  ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly
```

It seems that the rpath should be set to `@loader_path/../Frameworks`. I am not 
a Swift maestro so not exactly sure on the details of how this works. After 
running `install_name_tool -add_rpath "@loader_path/../Frameworks" 
./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly` it runs fine.

Does anyone have any idea what to do? Is it a missing CMake Swift feature? We 
are currently working around it by manually adding the rpath with a cmake step.

Harry

Harry Mallon

Senior Software Engineer

[http://codex.online/?action=asset=E3D62C3D-A12C-447D-87A5-F36E7C2AA9A4]

T +44 203 7000 989

60 Poland Street | London | England | W1F 7NT

[http://codex.online/?action=asset=6F42BDF2-3C6D-4054-A5D2-277E0E535942]
Three BillboardsBlade Runner 2049I, Tonya


-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] failure to build Cmake to / against non-standard directory under Linux

[Ben Sferrazza]

 I have a completely insulated boostrapped toolchain+binaries setup
(located under /home/tools), following much of the Linux From Scratch book,
that has been able to build everything that I throw at it. Most things just
work with a simple --prefix option, as I have also edited the GCC specs
file to include my /home/tools/include directory (using -isystem) and link
against my /home/tools/lib directory (also with an rpath set, so that all
binaries I build are complete insulated from the host libraries). The lone
exception to this is Cmake. It appears to have a lot of hardcoded paths in
its build environment to standard /usr/* directories.

I first got wind that something was awry when Cmake 3.10.2 claimed my
compiler, GCC 7.3.0, isn't C++11 compliant. Clearly this isn't the case,
given that it's the latest release. So I then tried building Cmake 3.9.6,
which doesn't require C++11, and it was finding zlib and other libraries
under /usr/lib as opposed to my /home/tools/lib. I don't even have
LD_LIBRARY_PATH set, as I use rpath in the specs file like I mentioned. Can
anyone provide any help into how I can get Cmake to build against
non-standard include and library locations?

Thank you,
Ben
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] add_custom_target

[Mark De Wit]

Oh good point on OpenSSL, their official build steps are awkard enough, let 
alone trying to emulate them in CMake!

For what it's worth, we've upgraded boost-cmake to Boost 1.65 so far with no 
changes required to any of the modules we use.

The other 3rd party module manager we're looking into is Conan (conan.io), 
which can create CMake import libraries / targets.  It's a complex tool to 
understand, though.

I see in your mail that you're using a file to write SHA tags of your current 
3rd party modules.  Boost-cmake does a similar thing, but it stores it in the 
cmake cache, perhaps slightly easier to work with?

Do I understand correctly that you're using this external file as a dependency 
from which to trigger a 3rd party module build?  But cmake isn't detecting 
changes / running the custom commands that are dependent on that file?   Might 
it help to add the file to one of your own projects, eg one of the projects 
that depends on boost / openssl?  From memory, I believe cmake only cares about 
files if they're actually part of a target (unsure if custom targets count)?

Mark
-Original Message-
From: Cameron Palmer [mailto:came...@promon.no] 
Sent: 02 March 2018 13:21
To: Mark De Wit 
Cc: cmake@cmake.org
Subject: Re: add_custom_target

Interesting project, so thanks for the link!

The problem we have is that changing the build system for external projects 
isn’t really acceptable. In this boost-cmake build they ripped out jam and 
replaced it with cmake, which is kind of cool, but such action is not a good 
plan for OpenSSL. If I recall they state (somewhere) in the documentation, 
don’t do this and even if it did work, I wouldn’t want to support it. 
Furthermore, it looks like you’d also be stuck using 1.63.0 of Boost. In 
summary, there is a lot of compromise involved in trying to replace a 
build-system, better to wrap it.


Cameron.

> On 2 Mar 2018, at 13:02, Mark De Wit  wrote:
> 
> Hi Cameron,
> 
> For boost integration into our cmake project, we're using this (slightly 
> customised for our use):
> https://github.com/Orphis/boost-cmake
> 
> It unzips boost into your build folder, and builds the required packages on 
> demand (not all of boost, just the boost modules you use).  
> 
> It works well for incremental builds (doesn't rebuild unless you clear your 
> build folder), and for clean builds the individual boost modules build fast 
> enough to be insignificant.  I'd also point out that the build time increase 
> is somewhat balanced out by not fetching tens of thousands files from source 
> control...
> 
> This may help shape your thinking?   
> 
> Mark
> 
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Cameron Palmer
> Sent: 02 March 2018 11:22
> To: cmake@cmake.org
> Subject: [CMake] add_custom_target
> 
> I’m using ExternalProject_Add to download a Git project that is a 
> pre-requisite of my project. For the sake of the discussion I’ve wrapped 
> OpenSSL and Boost in this manner placing tagged version of the source in my 
> repo.
> 
> Building them isn’t really a problem, they run, take a long time compiling. 
> The thing is, they should only compile once unless the tag changes. From the 
> source it seems once you’ve used git you’ll always trigger the whole External 
> Build sequence which is a pain since it is slow. So… I’ve been trying to 
> create an external build just for the Git checkout and a second for the 
> compilation. Which goes well enough, but I still need the glue to signal that 
> he source is ‘dirty’ and it should recompile the project.
> 
> The glue I’m trying to use is add_custom_command and add_custom_target, but 
> add_custom_target seems… broken if only in concept. I’ve been trying to write 
> a file to the system with the SHA tag and only touch it when it changes, but 
> I cannot convince the ExternalProject that builds the library to not run.
> 
> Any tips that might make this work?
> -- 
> 
> 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:
> https://cmake.org/mailman/listinfo/cmake

-- 

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: 

Re: [CMake] add_custom_target

[Cameron Palmer]

Interesting project, so thanks for the link!

The problem we have is that changing the build system for external projects 
isn’t really acceptable. In this boost-cmake build they ripped out jam and 
replaced it with cmake, which is kind of cool, but such action is not a good 
plan for OpenSSL. If I recall they state (somewhere) in the documentation, 
don’t do this and even if it did work, I wouldn’t want to support it. 
Furthermore, it looks like you’d also be stuck using 1.63.0 of Boost. In 
summary, there is a lot of compromise involved in trying to replace a 
build-system, better to wrap it.


Cameron.

> On 2 Mar 2018, at 13:02, Mark De Wit  wrote:
> 
> Hi Cameron,
> 
> For boost integration into our cmake project, we're using this (slightly 
> customised for our use):
> https://github.com/Orphis/boost-cmake
> 
> It unzips boost into your build folder, and builds the required packages on 
> demand (not all of boost, just the boost modules you use).  
> 
> It works well for incremental builds (doesn't rebuild unless you clear your 
> build folder), and for clean builds the individual boost modules build fast 
> enough to be insignificant.  I'd also point out that the build time increase 
> is somewhat balanced out by not fetching tens of thousands files from source 
> control...
> 
> This may help shape your thinking?   
> 
> Mark
> 
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Cameron Palmer
> Sent: 02 March 2018 11:22
> To: cmake@cmake.org
> Subject: [CMake] add_custom_target
> 
> I’m using ExternalProject_Add to download a Git project that is a 
> pre-requisite of my project. For the sake of the discussion I’ve wrapped 
> OpenSSL and Boost in this manner placing tagged version of the source in my 
> repo.
> 
> Building them isn’t really a problem, they run, take a long time compiling. 
> The thing is, they should only compile once unless the tag changes. From the 
> source it seems once you’ve used git you’ll always trigger the whole External 
> Build sequence which is a pain since it is slow. So… I’ve been trying to 
> create an external build just for the Git checkout and a second for the 
> compilation. Which goes well enough, but I still need the glue to signal that 
> he source is ‘dirty’ and it should recompile the project.
> 
> The glue I’m trying to use is add_custom_command and add_custom_target, but 
> add_custom_target seems… broken if only in concept. I’ve been trying to write 
> a file to the system with the SHA tag and only touch it when it changes, but 
> I cannot convince the ExternalProject that builds the library to not run.
> 
> Any tips that might make this work?
> -- 
> 
> 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:
> https://cmake.org/mailman/listinfo/cmake

-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] add_custom_target

[Mark De Wit]

Hi Cameron,

For boost integration into our cmake project, we're using this (slightly 
customised for our use):
https://github.com/Orphis/boost-cmake

It unzips boost into your build folder, and builds the required packages on 
demand (not all of boost, just the boost modules you use).  

It works well for incremental builds (doesn't rebuild unless you clear your 
build folder), and for clean builds the individual boost modules build fast 
enough to be insignificant.  I'd also point out that the build time increase is 
somewhat balanced out by not fetching tens of thousands files from source 
control...

This may help shape your thinking?   

Mark

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Cameron Palmer
Sent: 02 March 2018 11:22
To: cmake@cmake.org
Subject: [CMake] add_custom_target

I’m using ExternalProject_Add to download a Git project that is a pre-requisite 
of my project. For the sake of the discussion I’ve wrapped OpenSSL and Boost in 
this manner placing tagged version of the source in my repo.

Building them isn’t really a problem, they run, take a long time compiling. The 
thing is, they should only compile once unless the tag changes. From the source 
it seems once you’ve used git you’ll always trigger the whole External Build 
sequence which is a pain since it is slow. So… I’ve been trying to create an 
external build just for the Git checkout and a second for the compilation. 
Which goes well enough, but I still need the glue to signal that he source is 
‘dirty’ and it should recompile the project.

The glue I’m trying to use is add_custom_command and add_custom_target, but 
add_custom_target seems… broken if only in concept. I’ve been trying to write a 
file to the system with the SHA tag and only touch it when it changes, but I 
cannot convince the ExternalProject that builds the library to not run.

Any tips that might make this work?
-- 

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:
https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] add_custom_target

[Cameron Palmer]

I’m using ExternalProject_Add to download a Git project that is a pre-requisite 
of my project. For the sake of the discussion I’ve wrapped OpenSSL and Boost in 
this manner placing tagged version of the source in my repo.

Building them isn’t really a problem, they run, take a long time compiling. The 
thing is, they should only compile once unless the tag changes. From the source 
it seems once you’ve used git you’ll always trigger the whole External Build 
sequence which is a pain since it is slow. So… I’ve been trying to create an 
external build just for the Git checkout and a second for the compilation. 
Which goes well enough, but I still need the glue to signal that he source is 
‘dirty’ and it should recompile the project.

The glue I’m trying to use is add_custom_command and add_custom_target, but 
add_custom_target seems… broken if only in concept. I’ve been trying to write a 
file to the system with the SHA tag and only touch it when it changes, but I 
cannot convince the ExternalProject that builds the library to not run.

Any tips that might make this work?
-- 

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:
https://cmake.org/mailman/listinfo/cmake