Re: [cmake-developers] New policy to address rdynamic

2015-08-31 Thread Chuck Atkins 
So, from what I can tell, the Visual Studio generator and Xcode generator
don't even use the CMAKE_SHARED_LIBRARY_LINK__FLAGS.  I know it's the
generators and not platforms since my tests pass on these platforms with
Makefile and Ninja generators but fail with Visual Studio and Xcode
generators.  Is this common to all multi-config generators or just these
two? I'm trying to determine under which circumstances the policy is even
applicable.

- Chuck

On Wed, Aug 26, 2015 at 6:30 PM, Chuck Atkins 
wrote:

> Maybe
>>
>>  [TARGET_PROPERTIES   [ ]... ]
>>
>> makes sense instead?
>>
>> That would allow setting ANDROID_API, WIN32_EXECUTABLE etc.
>>
>
> Good idea!  I actually do like that better, but it's outside the scope of
> this change.  For now I'll remove the ENABLE_EXPORTS but still propagate
> the policy and then push a separate branch to add the TARGET_PROPERTIES
> argument.
>
> Thanks
> - Chuck
>
-- 

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] New policy to address rdynamic

2015-08-31 Thread Brad King 
On 08/31/2015 03:44 PM, Chuck Atkins wrote:
> the Visual Studio generator and Xcode generator
> don't even use the CMAKE_SHARED_LIBRARY_LINK__FLAGS

This is likely true and has not been noticed because the
Platform modules do not set any value for this variable
on any platform supported by those generators.  Those
generators could be fixed and it would not change anything
for existing platforms.

-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

Re: [cmake-developers] New policy to address rdynamic

2015-08-26 Thread Stephen Kelly 
Chuck Atkins wrote:

 I've implemented a new policy, CMP0065, to restrict the addition of
 CMAKE_SHARED_LIBRARY_LINK_LANG_FLAGS to executables to only when the
 ENABLE_EXPORTS target property is set.  This should allow us to preserve
 backwards compatibility in the places it breaks existing binaries but
 allow us to remove it by default for newer projects.
 
 See stage/restrict-shlib-link-flags-to-enable-exports
 
 The motivator behind this is to get closer to easily supporting fully
 static binaries..  Any feedback would be appreciated.

You add an

 [ENABLE_EXPORTS] 

keyword to try_compile. Maybe 

 [TARGET_PROPERTIES prop1 value1 [prop1 value1]... ]

makes sense instead? 

That would allow setting ANDROID_API, WIN32_EXECUTABLE etc.

Thanks,

Steve.

-- 

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] New policy to address rdynamic

2015-08-26 Thread Chuck Atkins 
I've implemented a new policy, CMP0065, to restrict the addition of
CMAKE_SHARED_LIBRARY_LINK_LANG_FLAGS to executables to only when the
ENABLE_EXPORTS target property is set.  This should allow us to preserve
backwards compatibility in the places it breaks existing binaries but allow
us to remove it by default for newer projects.

See stage/restrict-shlib-link-flags-to-enable-exports

The motivator behind this is to get closer to easily supporting fully
static binaries..  Any feedback would be appreciated.

- Chuck
-- 

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] New policy to address rdynamic

2015-08-26 Thread Chuck Atkins 

 Maybe

  [TARGET_PROPERTIES prop1 value1 [prop1 value1]... ]

 makes sense instead?

 That would allow setting ANDROID_API, WIN32_EXECUTABLE etc.


Good idea!  I actually do like that better, but it's outside the scope of
this change.  For now I'll remove the ENABLE_EXPORTS but still propagate
the policy and then push a separate branch to add the TARGET_PROPERTIES
argument.

Thanks
- Chuck
-- 

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