[Cmake-commits] CMake branch, master, updated. v3.8.0-829-g1b0c7bc

2017-04-20 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  1b0c7bca5ede6eb3965cb23471c6530a08d0d2d5 (commit)
  from  b4d3cdc8c504ddc5d2618203a831c950f8d0102a (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=1b0c7bca5ede6eb3965cb23471c6530a08d0d2d5
commit 1b0c7bca5ede6eb3965cb23471c6530a08d0d2d5
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Apr 21 00:01:12 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Apr 21 00:01:12 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 737087f..ea6e0e2 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 8)
-set(CMake_VERSION_PATCH 20170420)
+set(CMake_VERSION_PATCH 20170421)
 #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
http://public.kitware.com/mailman/listinfo/cmake-commits


Re: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl

2017-04-20 Thread Michael Ellery
It doesn’t look like that find module directly supports HINTS or PATHS, so you 
can try setting CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH  
(https://cmake.org/cmake/help/v3.7/variable/CMAKE_LIBRARY_PATH.html) before 
calling the curl finder. I think you can add to those variables whatever paths 
are appropriate to search for CURL on your systems.

-Mike

> On Apr 20, 2017, at 6:06 PM, Alex Chen  wrote:
> 
> The source code I want to compile on Linux uses ‘FindOpenSSL’, ‘FindZLIB’, 
> and ‘FindCURL’ to resolve the paths of these libraries.
> However, I have newer version of these libraries in different locations.  How 
> to I override these to use my paths?
> I am able to use OPENSSL_ROOT_DIR, from FindOpenSSL module, and ZLIB_ROOT, 
> from FindZLIB module, to override the paths.  
> But I cannot find anything in FindCURL module to override the path of libcurl.
>  
>  
> Alex Chen
> -- 
> 
> 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:
> http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl

2017-04-20 Thread Alex Chen
The source code I want to compile on Linux uses ‘FindOpenSSL’, ‘FindZLIB’, and 
‘FindCURL’ to resolve the paths of these libraries.

However, I have newer version of these libraries in different locations.  How 
to I override these to use my paths?

I am able to use OPENSSL_ROOT_DIR, from FindOpenSSL module, and ZLIB_ROOT, from 
FindZLIB module, to override the paths.  

But I cannot find anything in FindCURL module to override the path of libcurl.

 

 

Alex Chen

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to set C++ standard?

2017-04-20 Thread Alex Chen
Thanks.  I find the problem in the source code where it uses CPP_STANDARD as 
suffix in –std=c++, therefore I should set CPP_STANDARD instead of the other 
one.

 

 

Alex Chen

 

From: Craig Scott 
Date: Thursday, April 20, 2017 at 4:41 PM
To: Alex Chen 
Cc: CMake 
Subject: Re: [CMake] How to set C++ standard?

 

You generally shouldn't set CMAKE_CXX_STANDARD on its own, you should also be 
explicitly setting CMAKE_CXX_STANDARD_REQUIRED and CMAKE_CXX_EXTENSIONS to 
ensure you are getting the behaviour you want. These would also typically be 
set by the project's own CMakeLists.txt file rather than being passed on the 
cmake command line as cache variables. You may find the following article 
helpful:

 

https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/

 

 

 

On Fri, Apr 21, 2017 at 8:57 AM, Alex Chen  wrote:

I tried to set the compiler flag –std=c++14 via cmake command line on Linux 
with –DCMAKE_CXX_STANDARD=14.  The message from ‘make’ shows   -std=c++11 
–std=gnu++14

If I do not set that flag, I get -std=c++11.  This seem to imply the 
CMAKE_CXX_STANDARD flag sets gnu++ instead of c++.  How do I set the flag 
–std=c++14 then?

 

Alex Chen


--

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:
http://public.kitware.com/mailman/listinfo/cmake



 

-- 

Craig Scott

Melbourne, Australia

https://crascit.com

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] dependency on external libraries (and Visual Studio)

2017-04-20 Thread Kris Thielemans
Hi

 

I have a project with a shared library that depends on some external static
libraries. Those are CMake imported targets. It appears that my shared
library does not get rebuild when the external libraries are updated. (It
would need to be relinked). Is this expected?

 

A bit more info on my set-up:

CMake 3.8.0

Visual Studio Community 2015

 

Some content of my CMakeLists.txt (the external libraries are set in
$(STIR_LIBRARIES}). Full project is on https://github.com/CCPPETMR/SIRF/

 

# static library depending on external

add_library(cstir cstir_p.cpp)

target_link_libraries(cstir ${STIR_LIBRARIES})

 

# shared library depending on external (probably not necessary as depends on
cstir already)

add_library(mstir SHARED mstir.c)

target_link_libraries(mstir  cstir ${STIR_LIBRARIES})

 

When checking the Visual Studio project, mstir has a "Reference" to cstir,
but neither of them refers to any of the externals.

 

Thanks

Kris

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to set C++ standard?

2017-04-20 Thread Craig Scott
You generally shouldn't set CMAKE_CXX_STANDARD on its own, you should also
be explicitly setting CMAKE_CXX_STANDARD_REQUIRED and CMAKE_CXX_EXTENSIONS
to ensure you are getting the behaviour you want. These would also
typically be set by the project's own CMakeLists.txt file rather than being
passed on the cmake command line as cache variables. You may find the
following article helpful:

https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/



On Fri, Apr 21, 2017 at 8:57 AM, Alex Chen  wrote:

> I tried to set the compiler flag –std=c++14 via cmake command line on
> Linux with –DCMAKE_CXX_STANDARD=14.  The message from ‘make’ shows   
> *-std=c++11
> –std=gnu++14*
>
> If I do not set that flag, I get *-std=c++11.  *This seem to imply the
> CMAKE_CXX_STANDARD flag sets *gnu++* instead of *c++.  *How do I set the
> flag –std=c++14 then?
>
>
>
> Alex Chen
>
> --
>
> 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:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] How to set C++ standard?

2017-04-20 Thread Alex Chen
I tried to set the compiler flag –std=c++14 via cmake command line on Linux 
with –DCMAKE_CXX_STANDARD=14.  The message from ‘make’ shows   -std=c++11 
–std=gnu++14

If I do not set that flag, I get -std=c++11.  This seem to imply the 
CMAKE_CXX_STANDARD flag sets gnu++ instead of c++.  How do I set the flag 
–std=c++14 then?

 

Alex Chen

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] Proposal to disable link depends inference.

2017-04-20 Thread Matthew Hanna (BLOOMBERG/ 731 LEX)
After checking several approaches, it looks as though the number of
edges in the inference algorithm is the bottleneck, regardless of the
number of cycles inferred.  In our particular case, the number of
external dependencies far outnumbers the known, internal libraries.
Also, since we are using pkg-config, the external dependencies are
not well ordered, so inferences involving two external deps are bound
to be misleading.  Given that, the approach we are considering is to
avoid adding the external to external edges, but still leave all edges
that contain at least one known library.  The desired effect is
sketched out in the following commit:

https://gitlab.kitware.com/mhanna21/cmake/commit/2c7d2e33b6218e58f88957fb793ce0a781ec76aa

Thanks,
Matthew

From: mhann...@bloomberg.net At: 04/11/17 12:05:50
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Proposal to disable link depends inference.

Yes, disabling the 'magic guessing' is the primary goal.  I just wanted
to test the waters before embarking on a patch.  Will continue the
conversation once I have a patch ready that solves our problem.

Thanks,
Matthew
From: brad.k...@kitware.com At: 04/11/17 11:16:27
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Proposal to disable link depends inference.

On 04/11/2017 09:34 AM, Matthew Hanna (BLOOMBERG/ 731 LEX) wrote:
> The inference logic in cmComputeLinkDepends.cxx is both inefficient and
> superfluous for our specific use case. I am proposing a global setting that
> would disable the link computation entirely for those that wish to take full
> responsibility of the ordering of dependencies.

IIUC you're not talking about disabling the entire dependency analysis
but instead just turning off the magic guessing of implicit dependencies
based on observed order.  Correct?

Before we bikeshed the name and form of the setting, can you post a patch
that just removes the logic outright so we can see exactly what you mean?

Thanks,
-Brad

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers


 -- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers  

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Support for unified headers in Android NDK

2017-04-20 Thread Florent Castelli
I just came back from some holidays now, I'll try to update the MR with the
latest changes soon next week!

/Florent

On Apr 20, 2017 10:10 PM, "Robert Dailey"  wrote:

> I may pick this up, because right now it's impossible to use libc++
> (LLVM) with an API less than 21 since that's when clang was
> introduced. libc is missing too many symbols that are required by
> libc++ below API 21.
>
> On Thu, Apr 20, 2017 at 2:52 PM, Ben Boeckel 
> wrote:
> > On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
> >> Google is supporting unified headers for sysroot as of NDK r14:
> >>
> >> https://android.googlesource.com/platform/ndk/+/master/
> docs/UnifiedHeaders.md
> >>
> >> Is there a plan to add support for this natively into CMake?
> >
> > There is a merge request that is in-progress, but was closed due to
> > inactivity (lack of time on Florent's side it seems). I'd recommend
> > coordinating with Florent to resurrect the MR.
> >
> > https://gitlab.kitware.com/cmake/cmake/merge_requests/492
> >
> > --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:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Support for unified headers in Android NDK

2017-04-20 Thread Robert Dailey
I may pick this up, because right now it's impossible to use libc++
(LLVM) with an API less than 21 since that's when clang was
introduced. libc is missing too many symbols that are required by
libc++ below API 21.

On Thu, Apr 20, 2017 at 2:52 PM, Ben Boeckel  wrote:
> On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
>> Google is supporting unified headers for sysroot as of NDK r14:
>>
>> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
>>
>> Is there a plan to add support for this natively into CMake?
>
> There is a merge request that is in-progress, but was closed due to
> inactivity (lack of time on Florent's side it seems). I'd recommend
> coordinating with Florent to resurrect the MR.
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/492
>
> --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:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] Support for unified headers in Android NDK

2017-04-20 Thread Ben Boeckel
On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
> Google is supporting unified headers for sysroot as of NDK r14:
> 
> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
> 
> Is there a plan to add support for this natively into CMake?

There is a merge request that is in-progress, but was closed due to
inactivity (lack of time on Florent's side it seems). I'd recommend
coordinating with Florent to resurrect the MR.

https://gitlab.kitware.com/cmake/cmake/merge_requests/492

--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:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] Support for unified headers in Android NDK

2017-04-20 Thread Brad King
On 04/20/2017 03:31 PM, Robert Dailey wrote:
> Google is supporting unified headers for sysroot as of NDK r14:
> 
> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
> 
> Is there a plan to add support for this natively into CMake?

See issue here:

 https://gitlab.kitware.com/cmake/cmake/issues/16584

Linked from the issue is a partially completed MR to fix it but
it was never finished to the point of being ready to merge.

-Brad

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers


[cmake-developers] Support for unified headers in Android NDK

2017-04-20 Thread Robert Dailey
Google is supporting unified headers for sysroot as of NDK r14:

https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md

Is there a plan to add support for this natively into 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:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [CMake] Prevent libraries from linking twice during LLVM build

2017-04-20 Thread Michael Kruse
The cmake mailing list may not have sufficient context, so let me add
some details.

Polly is an extension library for LLVM. Both can be configured in
multiple configurations:

LLVM can be
- A bunch of libLLVM*.a files
- A bunch of libLLVM*.so files
- A single libLLVM.so file

Polly can be
- LLVMPolly.so to be loaded dynamically into the LLVM host application
  using an LD_PRELOAD-like mechanism (e.g. clang or opt)
- Linked directly into the LLVM host application (target_link_library)
  - as dynamic library libPolly.so
  - as static library libPolly.a

and it should work with all combinations of these.

The issue is not all host applications always have all LLVM components
linked into it. In the example below, there is the Julia compiler
which does not have the NVPTX backend in it, but it is required by
(some configuration of) Polly.

Hence if we have an LLVMPolly.so we don't know whether the host
program has the LLVMNVPTX* libraries in it. If we do not depend on
these libraries, the linker will complain about missing symbols if the
host doesn't have these either. If we do depend on these libraries,
and the host has them as well, we risk having the same library
multiple times in the address space (e.g. LLVMNVPTX* is statically
linked into libLLVM.so, but LLVMPolly.so contains them as well). This
is a problem, because for instance, static initializers (".ctors")
register some command-line options. It is an error if two libraries
(or two copies of the same library) register the same command-line
option twice.

This is not really a cmake-specific question, and the solution I
proposed to Sanjay to require the host application to have all
required components already linked into it. We can do this for clang,
opt (and bugpoint), but the Julia compiler guys do not like to depend
on the NVPTX backend, which they usually do not use.

Michael


2017-04-20 17:56 GMT+02:00 Sanjay Srivallabh Singapuram
:
> Hello,
>
> I'm proposing a patch to the Polly/LLVM project that involves linking
> libPolly.a or libPolly.so to NVPTX back-end libraries. I'm currently using,
> target_link_libraries(Polly
>   LLVMNVPTXCodeGen
>   LLVMNVPTXInfo
>   LLVMNVPTXDesc
>   LLVMNVPTXAsmPrinter
>   )
>
> The opt binary links to both Polly and NVPTX back-end libraries, therefore
> including the back-end libraries twice which causes problems. Can linking
> the libraries as an INTERFACE to Polly solve the problem ?
>
> target_link_libraries(Polly INTERFACE
>   LLVMNVPTXCodeGen
>   LLVMNVPTXInfo
>   LLVMNVPTXDesc
>   LLVMNVPTXAsmPrinter
>   )
>
> Thank You,
> Sanjay
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake


[CMake] Prevent libraries from linking twice during LLVM build

2017-04-20 Thread Sanjay Srivallabh Singapuram
Hello,

I'm proposing a patch to the Polly/LLVM project that involves linking
libPolly.a or libPolly.so to NVPTX back-end libraries. I'm currently using,
target_link_libraries(Polly
  LLVMNVPTXCodeGen
  LLVMNVPTXInfo
  LLVMNVPTXDesc
  LLVMNVPTXAsmPrinter
  )

The opt binary links to both Polly and NVPTX back-end libraries, therefore
including the back-end libraries twice which causes problems. Can linking
the libraries as an INTERFACE to Polly solve the problem ?

target_link_libraries(Polly INTERFACE
  LLVMNVPTXCodeGen
  LLVMNVPTXInfo
  LLVMNVPTXDesc
  LLVMNVPTXAsmPrinter
  )

Thank You,
Sanjay
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, release, updated. v3.8.0-4-gb99fbf3

2017-04-20 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  b99fbf3b16449a6027e90ed7f01f240761157332 (commit)
   via  2516bccdf69b49ee55ef4b6bfa329d97ec5f3799 (commit)
   via  f612719a77e46cff6c6258e1394547c3476a5a21 (commit)
   via  16ef163fd613d2c1c84ae9a9fa5a29ffcf7818de (commit)
  from  da7833c5bb1f331162d46a2c664a443c1c641089 (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 -
---

Summary of changes:
 Modules/FindBoost.cmake   |5 +++--
 Modules/FindOpenSSL.cmake |4 
 2 files changed, 7 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v3.8.0-828-gb4d3cdc

2017-04-20 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  b4d3cdc8c504ddc5d2618203a831c950f8d0102a (commit)
   via  24b04b51341c0575d9492d9d09a405112317e2cf (commit)
   via  6c7460bc48be10a774f54271340711bcfdef8fb5 (commit)
   via  01d72391b3974b63a348b59a0ad2c528f4e68bb4 (commit)
   via  96246fb9aff11c354d8b9e297f2864a70ab69000 (commit)
   via  09e3864b4b087c3484a8c81abc67d19599f8730b (commit)
   via  caabb6e1f3756f317a1b856ec43d77ea80295e04 (commit)
   via  0fd255adf52592e6443c15a68c09cfa7fc26e85b (commit)
   via  540b4cdc2bd7cb824c6cf7403857844b4fce4d6e (commit)
   via  c94f1bcf92bf5de100a1513cf1dd7f4eaf0122d4 (commit)
   via  a4452fd82df79c579ab3996e3c56c59964bf69ea (commit)
   via  6e66fe5f977c3d8e0a4b24236a00b31f325ef5a3 (commit)
   via  b99fbf3b16449a6027e90ed7f01f240761157332 (commit)
   via  2516bccdf69b49ee55ef4b6bfa329d97ec5f3799 (commit)
   via  f612719a77e46cff6c6258e1394547c3476a5a21 (commit)
   via  16ef163fd613d2c1c84ae9a9fa5a29ffcf7818de (commit)
   via  697a5d64d86d73b1353a90a5bfc9f444b97fedd7 (commit)
   via  5785482ce0be9187ff94c1042f8978d2f11285e8 (commit)
  from  3452f8b209176873288139572ac9a47f216ecfa1 (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=b4d3cdc8c504ddc5d2618203a831c950f8d0102a
commit b4d3cdc8c504ddc5d2618203a831c950f8d0102a
Merge: 24b04b5 b99fbf3
Author: Brad King 
AuthorDate: Thu Apr 20 08:50:27 2017 -0400
Commit: Brad King 
CommitDate: Thu Apr 20 08:50:27 2017 -0400

Merge branch 'release'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=24b04b51341c0575d9492d9d09a405112317e2cf
commit 24b04b51341c0575d9492d9d09a405112317e2cf
Merge: 6c7460b c94f1bc
Author: Brad King 
AuthorDate: Thu Apr 20 12:47:24 2017 +
Commit: Kitware Robot 
CommitDate: Thu Apr 20 08:47:26 2017 -0400

Merge topic 'remove-vs7.1-generator'

c94f1bcf Drop Visual Studio 7 .NET 2003 generator
a4452fd8 cmGlobalVisualStudioGenerator: Drop VS7 enumeration value
6e66fe5f cmGlobalVisualStudio8Generator: Drop unused GetDocumentation method

Acked-by: Kitware Robot 
Merge-request: !723


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c7460bc48be10a774f54271340711bcfdef8fb5
commit 6c7460bc48be10a774f54271340711bcfdef8fb5
Merge: 01d7239 2516bcc
Author: Brad King 
AuthorDate: Thu Apr 20 12:47:02 2017 +
Commit: Kitware Robot 
CommitDate: Thu Apr 20 08:47:05 2017 -0400

Merge topic 'FindBoost-fix-backslash-tolerance'

2516bccd FindBoost: Restore tolerance of backslashes in paths

Acked-by: Kitware Robot 
Merge-request: !721


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=01d72391b3974b63a348b59a0ad2c528f4e68bb4
commit 01d72391b3974b63a348b59a0ad2c528f4e68bb4
Merge: 96246fb 16ef163
Author: Brad King 
AuthorDate: Thu Apr 20 12:46:33 2017 +
Commit: Kitware Robot 
CommitDate: Thu Apr 20 08:46:47 2017 -0400

Merge topic 'FindOpenSSL-more-precompiled'

16ef163f FindOpenSSL: Add more library name alternatives

Acked-by: Kitware Robot 
Merge-request: !713


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96246fb9aff11c354d8b9e297f2864a70ab69000
commit 96246fb9aff11c354d8b9e297f2864a70ab69000
Merge: 09e3864 caabb6e
Author: Brad King 
AuthorDate: Thu Apr 20 12:45:57 2017 +
Commit: Kitware Robot 
CommitDate: Thu Apr 20 08:46:01 2017 -0400

Merge topic 'doc-dev-source-code'

caabb6e1 Help/dev: Adopt C++ subset rules in coding guide
0fd255ad Help/dev: Adopt clang-format instructions in coding guide
540b4cdc Help/dev: Add a CMake Source Code Guide placeholder

Acked-by: Kitware Robot 
Merge-request: !724


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09e3864b4b087c3484a8c81abc67d19599f8730b
commit 09e3864b4b087c3484a8c81abc67d19599f8730b
Merge: 3452f8b 697a5d6
Author: Brad King 
AuthorDate: Thu Apr 20 12:45:37 2017 +
Commit: Kitware Robot 
CommitDate: Thu Apr 20 08:45:42 2017 -0400

Merge topic 'update-kwsys'

697a5d64 Merge branch 'upstream-KWSys' into update-kwsys
5785482c KWSys 2017-04-19 (9f6ffaff)

Acked-by: Kitware Robot 
Merge-request: !716