Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-11-04 Thread Brad King 
On 11/02/2013 07:29 AM, Brad King wrote:
 Policy CMP0022's NEW behavior is supposed to be that the
 link interface is exactly specified by INTERFACE_LINK_LIBRARIES.
 Therefore in this case the plain tll signature should go
 ahead and populate *both* INTERFACE_LINK_LIBRARIES *and*
 LINK_LIBRARIES.

After working through the details of this over the weekend
the fix and a bunch of tests are now in master.  It ended
up taking several commits.  The main one is:

 CMP0022: Plain target_link_libraries must populate link interface
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef10b87c

Two other important changes are:

 Do not export INTERFACE_LINK_LIBRARIES from non-linkable targets
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23d21b78

 CMP0022: Warn about a given target at most once
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a561a03

I plan to include all this in 2.8.12.1.  Please test ASAP.

Thanks,
-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-11-04 Thread Clinton Stimpson 
On Monday, November 04, 2013 09:48:57 AM Brad King wrote:
 On 11/02/2013 07:29 AM, Brad King wrote:
  Policy CMP0022's NEW behavior is supposed to be that the
  link interface is exactly specified by INTERFACE_LINK_LIBRARIES.
  Therefore in this case the plain tll signature should go
  ahead and populate *both* INTERFACE_LINK_LIBRARIES *and*
  LINK_LIBRARIES.
 
 After working through the details of this over the weekend
 the fix and a bunch of tests are now in master.  It ended
 up taking several commits.  The main one is:
 
  CMP0022: Plain target_link_libraries must populate link interface
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef10b87c
 
 Two other important changes are:
 
  Do not export INTERFACE_LINK_LIBRARIES from non-linkable targets
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23d21b78
 
  CMP0022: Warn about a given target at most once
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a561a03
 
 I plan to include all this in 2.8.12.1.  Please test ASAP.
 
 Thanks,
 -Brad

The problem I reported before indeed appears fixed.

But I see 2 others new problems.


1)
cmake_minimum_required(VERSION 2.8)
add_library(foo SHARED foo.cpp)
add_library(bar SHARED bar.cpp)
target_link_libraries(bar foo)
set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
add_executable(exe exe.cpp)
target_link_libraries(exe bar)


With 2.8.12.1, I now get a new warning that I did not get with 2.8.12.  I'm 
not sure why I'm getting that warning because the linking of exe looks 
correct.

CMake Warning (dev) in CMakeLists.txt:
  Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
  interface.  Run cmake --help-policy CMP0022 for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  Target bar has an INTERFACE_LINK_LIBRARIES property which differs from
  its LINK_INTERFACE_LIBRARIES properties.
  INTERFACE_LINK_LIBRARIES:
foo
  LINK_INTERFACE_LIBRARIES:



2)
cmake_minimum_required(VERSION 2.8.12)
add_library(foo SHARED foo.cpp)
add_library(bar SHARED bar.cpp)
target_link_libraries(bar foo)
set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
add_executable(exe exe.cpp)
target_link_libraries(exe bar)

I get no warning or error, but my LINK_INTERFACE_LIBRARIES property was not 
respected and it linked both foo and bar into exe.  This appears to be a 
regression from 2.8.12 to 2.8.12.1.


-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-11-04 Thread Brad King 
On 11/04/2013 10:31 AM, Clinton Stimpson wrote:
 But I see 2 others new problems.

Those are features and they work together as intended.

 1)
 cmake_minimum_required(VERSION 2.8)
 add_library(foo SHARED foo.cpp)
 add_library(bar SHARED bar.cpp)
 target_link_libraries(bar foo)
 set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
 add_executable(exe exe.cpp)
 target_link_libraries(exe bar)
 
 With 2.8.12.1, I now get a new warning that I did not get with 2.8.12.  I'm 
 not sure why I'm getting that warning because the linking of exe looks 
 correct.
 
 CMake Warning (dev) in CMakeLists.txt:
   Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
   interface.  Run cmake --help-policy CMP0022 for policy details.  Use the
   cmake_policy command to set the policy and suppress this warning.
 
   Target bar has an INTERFACE_LINK_LIBRARIES property which differs from
   its LINK_INTERFACE_LIBRARIES properties.
   INTERFACE_LINK_LIBRARIES:
 foo
   LINK_INTERFACE_LIBRARIES:

This is a correct warning according to the definition of CMP0022.
The bug you reported in 2.8.12.0 also caused it to not warn here.
Prior to my fix CMake did not track the new INTERFACE_LINK_LIBRARIES
value correctly for the plain tll signature so it didn't realize
that things would change and therefore did not warn.

 2)
 cmake_minimum_required(VERSION 2.8.12)
 add_library(foo SHARED foo.cpp)
 add_library(bar SHARED bar.cpp)
 target_link_libraries(bar foo)
 set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
 add_executable(exe exe.cpp)
 target_link_libraries(exe bar)
 
 I get no warning or error, but my LINK_INTERFACE_LIBRARIES property was not 
 respected and it linked both foo and bar into exe.  This appears to be a 
 regression from 2.8.12 to 2.8.12.1.

This is also correct behavior.  The NEW behavior of CMP0022
is to ignore LINK_INTERFACE_LIBRARIES and use the new
INTERFACE_LINK_LIBRARIES which is now populated by the tll call.

The warning you get when the policy is not set is telling
you exactly what will change when the policy is set to NEW.
Therefore it gives you a chance to fix your code before setting
the policy (by bumping the min req version or explicitly).

This is exactly how policies are intended to work.  It was
very unfortunate that 2.8.12.0 was released without giving
projects any release candidates with a correct CMP0022 impl.

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-11-04 Thread Clinton Stimpson 
On Monday, November 04, 2013 10:40:15 AM Brad King wrote:
 On 11/04/2013 10:31 AM, Clinton Stimpson wrote:
  But I see 2 others new problems.
 
 Those are features and they work together as intended.
 
  1)
  cmake_minimum_required(VERSION 2.8)
  add_library(foo SHARED foo.cpp)
  add_library(bar SHARED bar.cpp)
  target_link_libraries(bar foo)
  set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
  add_executable(exe exe.cpp)
  target_link_libraries(exe bar)
  
  With 2.8.12.1, I now get a new warning that I did not get with 2.8.12. 
  I'm
  not sure why I'm getting that warning because the linking of exe looks
  correct.
  
  CMake Warning (dev) in CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface.  Run cmake --help-policy CMP0022 for policy details.  Use
the
cmake_policy command to set the policy and suppress this warning.

Target bar has an INTERFACE_LINK_LIBRARIES property which differs from
its LINK_INTERFACE_LIBRARIES properties.

INTERFACE_LINK_LIBRARIES:
  foo

LINK_INTERFACE_LIBRARIES:
 This is a correct warning according to the definition of CMP0022.
 The bug you reported in 2.8.12.0 also caused it to not warn here.
 Prior to my fix CMake did not track the new INTERFACE_LINK_LIBRARIES
 value correctly for the plain tll signature so it didn't realize
 that things would change and therefore did not warn.
 
  2)
  cmake_minimum_required(VERSION 2.8.12)
  add_library(foo SHARED foo.cpp)
  add_library(bar SHARED bar.cpp)
  target_link_libraries(bar foo)
  set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
  add_executable(exe exe.cpp)
  target_link_libraries(exe bar)
  
  I get no warning or error, but my LINK_INTERFACE_LIBRARIES property was
  not
  respected and it linked both foo and bar into exe.  This appears to be a
  regression from 2.8.12 to 2.8.12.1.
 
 This is also correct behavior.  The NEW behavior of CMP0022
 is to ignore LINK_INTERFACE_LIBRARIES and use the new
 INTERFACE_LINK_LIBRARIES which is now populated by the tll call.
 
 The warning you get when the policy is not set is telling
 you exactly what will change when the policy is set to NEW.
 Therefore it gives you a chance to fix your code before setting
 the policy (by bumping the min req version or explicitly).
 
 This is exactly how policies are intended to work.  It was
 very unfortunate that 2.8.12.0 was released without giving
 projects any release candidates with a correct CMP0022 impl.


Ok.  Yes, that threw me off when the cmp0022 behavior wasn't correct in 
2.8.12.0.  And I agree that it is fixed in 2.8.12.1.

Thanks,
Clint
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-11-04 Thread Clinton Stimpson 
On Monday, November 04, 2013 09:16:11 AM Clinton Stimpson wrote:
 On Monday, November 04, 2013 10:40:15 AM Brad King wrote:
  On 11/04/2013 10:31 AM, Clinton Stimpson wrote:
   But I see 2 others new problems.
  
  Those are features and they work together as intended.
  
   1)
   cmake_minimum_required(VERSION 2.8)
   add_library(foo SHARED foo.cpp)
   add_library(bar SHARED bar.cpp)
   target_link_libraries(bar foo)
   set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
   add_executable(exe exe.cpp)
   target_link_libraries(exe bar)
   
   With 2.8.12.1, I now get a new warning that I did not get with 2.8.12.
   I'm
   not sure why I'm getting that warning because the linking of exe looks
   correct.
   
   CMake Warning (dev) in CMakeLists.txt:
 Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
 interface.  Run cmake --help-policy CMP0022 for policy details.  Use
 the
 cmake_policy command to set the policy and suppress this warning.
 
 Target bar has an INTERFACE_LINK_LIBRARIES property which differs
 from
 its LINK_INTERFACE_LIBRARIES properties.
 
 INTERFACE_LINK_LIBRARIES:
   foo
 
 LINK_INTERFACE_LIBRARIES:
  This is a correct warning according to the definition of CMP0022.
  The bug you reported in 2.8.12.0 also caused it to not warn here.
  Prior to my fix CMake did not track the new INTERFACE_LINK_LIBRARIES
  value correctly for the plain tll signature so it didn't realize
  that things would change and therefore did not warn.
  

And I think that is part of why I submitted bug 
http://cmake.org/Bug/view.php?id=14512
where I was not getting a warning when I should have.  It was possible to go 
from CMake 2.8.10 to CMake 2.8.12 and not get any warning about behavior 
change.

Thanks for fixing this.

Clint


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-11-02 Thread Brad King 
On 11/1/2013 3:25 PM, Brad King wrote:
 On third thought, the tll documentation for the plain signature
 does not say it populates the INTERFACE_LINK_LIBRARIES property.

[smacks forehead]

On fourth thought I realized this is exactly the problem!
This is a policy, so the NEW behavior can be whatever we
need it to be.  There is no reason plain tll can't set the
INTERFACE_LINK_LIBRARIES when the policy is NEW.

Policy CMP0022's NEW behavior is supposed to be that the
link interface is exactly specified by INTERFACE_LINK_LIBRARIES.
Therefore in this case the plain tll signature should go
ahead and populate *both* INTERFACE_LINK_LIBRARIES *and*
LINK_LIBRARIES.

Now we can restore your logic in ComputLinkInterface to not
use the link implementation when CMP0022 is NEW.

I extended the topic to change to this approach, and then
squashed it all back together since the net change is now
pretty simple.

Note that supporting pre-2.8.12 clients is again as simple as

 get_property(iface TARGET foo PROPERTY INTERFACE_LINK_LIBRARIES)
 set_property(TARGET foo PROPERTY LINK_INTERFACE_LIBRARIES ${iface})

and using EXPORT_LINK_INTERFACE_LIBRARIES.

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-11-01 Thread Stephen Kelly 
Brad King wrote:

 Can you explain what the comment about LINK_LIBRARIES means?

The comment carried the (now known to be mistaken) assumption that the 
implementation is only ever the interface if CMP0022 is OLD.

If it is NEW, then the INTERFACE_LINK_LIBRARIES defines the link interface 
(exclusively and always, as the assumption went), and as the preceeding 
if(explicitLibraries) was not entered, it was not set, and therefore there 
is no link interface at all.

 It is the logic here that needs to trigger regardless of the CMP0022
 setting, and then the export logic must deal with the case that the
 implementation is the interface both for populating the new and
 old interface properties.

Your commit, and my follow up from today don't pass this test:
 
 add_library(foo SHARED foo.cpp)
 add_library(bar SHARED foo.cpp)
 # target_link_libraries(foo bar)
 set_property(TARGET foo PROPERTY LINK_LIBRARIES bar)
 file(GENERATE OUTPUT outputfile 
   CONTENT $TARGET_PROPERTY:foo,INTERFACE_LINK_LIBRARIES\n)
 # Expect outputfile to contain 'bar', but it does not.


That was a primary motivation for introducing INTERFACE_LINK_LIBRARIES.

So, I guess we should add something similar to the export logic to the genex 
TargetPropertyNode. Any comments on that?

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-11-01 Thread Brad King 
On 11/01/2013 07:32 AM, Stephen Kelly wrote:
 Your commit, and my follow up from today don't pass this test:

In your follow up, you removed my hunk:

-  // Make sure INTERFACE_LINK_LIBRARIES target property exists
-  // if any signature except the plain one was used.  Other
-  // signatures imply awareness of explicit link interfaces.
-  if(this-CurrentProcessingState != ProcessingLinkLibraries 
- !this-Target-GetProperty(INTERFACE_LINK_LIBRARIES))
-{
-this-Target-SetProperty(INTERFACE_LINK_LIBRARIES, );
-}

What is wrong with it?  The documentation of the tll signatures
besides the plain one says that they set INTERFACE_LINK_LIBRARIES.
Shouldn't it get set to empty if a non-plain signature is used
that doesn't add anything to the interface?

  add_library(foo SHARED foo.cpp)
  add_library(bar SHARED foo.cpp)
  # target_link_libraries(foo bar)
  set_property(TARGET foo PROPERTY LINK_LIBRARIES bar)
  file(GENERATE OUTPUT outputfile 
CONTENT $TARGET_PROPERTY:foo,INTERFACE_LINK_LIBRARIES\n)
  # Expect outputfile to contain 'bar', but it does not.
 
 That was a primary motivation for introducing INTERFACE_LINK_LIBRARIES.
 
 So, I guess we should add something similar to the export logic to the genex 
 TargetPropertyNode. Any comments on that?

I think we should encourage use of the tll keyword signatures
in which case this doesn't matter.  However, we can try to support
this.  Perhaps the implementation of cmTarget::GetProperty can
special-case INTERFACE_LINK_LIBRARIES to return LINK_LIBRARIES
if only the plain tll signature was used.  That will cover both
the export and generator expression cases, no?

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-11-01 Thread Brad King 
On 11/01/2013 08:49 AM, Brad King wrote:
 On 11/01/2013 07:32 AM, Stephen Kelly wrote:
  add_library(foo SHARED foo.cpp)
  add_library(bar SHARED foo.cpp)
  # target_link_libraries(foo bar)
  set_property(TARGET foo PROPERTY LINK_LIBRARIES bar)
  file(GENERATE OUTPUT outputfile 
CONTENT $TARGET_PROPERTY:foo,INTERFACE_LINK_LIBRARIES\n)
  # Expect outputfile to contain 'bar', but it does not.

Actually, why would we expect 'bar' when setting LINK_LIBRARIES
directly?  Without the old plain tll() calls I see no reason to
expect the link interface to be the link implementation.

The link implementation fallback is only for compatibility with
the long-standing tll plain signature behavior.  If a project
sets link information by other means then it takes responsibility
for setting the link interface too.

 Perhaps the implementation of cmTarget::GetProperty can
 special-case INTERFACE_LINK_LIBRARIES to return LINK_LIBRARIES
 if only the plain tll signature was used.

On second thought, this is a bad idea because it could trigger
in a get_property call or something earlier than the last tll
call.

So yes, hacking the generator expression node for the fallback
is probably the right fix.

Please also work on the test cases.

Thanks,
-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-10-31 Thread Brad King 
On 10/30/2013 11:20 AM, Brad King wrote:
 Also please add the corresponding test case and base the topic
 on v2.8.12~2 so we can merge it for 2.8.12.1 after it passes
 in 'next'.

Thanks.  It appears that ImplementationIsInterface bypasses the
checks for EXPORT_LINK_INTERFACE_LIBRARIES and produces the
IMPORTED_LINK_INTERFACE_LIBRARIES properties even when CMP0022
is set to NEW.  Shouldn't it instead transform the link impl
into INTERFACE_LINK_LIBRARIES in exports, and also transform
the link impl into IMPORTED_LINK_INTERFACE_LIBRARIES subject
to EXPORT_LINK_INTERFACE_LIBRARIES?

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-10-31 Thread Brad King 
On 10/31/2013 09:19 AM, Brad King wrote:
 Thanks.  It appears that ImplementationIsInterface bypasses the
 checks for EXPORT_LINK_INTERFACE_LIBRARIES and produces the
 IMPORTED_LINK_INTERFACE_LIBRARIES properties even when CMP0022
 is set to NEW.  Shouldn't it instead transform the link impl
 into INTERFACE_LINK_LIBRARIES in exports, and also transform
 the link impl into IMPORTED_LINK_INTERFACE_LIBRARIES subject
 to EXPORT_LINK_INTERFACE_LIBRARIES?

I forgot to mention that in code paths prior to this fix the
ImplementationIsInterface could only be true if CMP0022 is
not NEW.

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-10-31 Thread Stephen Kelly 
Brad King wrote:

 On 10/30/2013 11:20 AM, Brad King wrote:
 Also please add the corresponding test case and base the topic
 on v2.8.12~2 so we can merge it for 2.8.12.1 after it passes
 in 'next'.
 
 Thanks.  It appears that ImplementationIsInterface bypasses the
 checks for EXPORT_LINK_INTERFACE_LIBRARIES and produces the
 IMPORTED_LINK_INTERFACE_LIBRARIES properties even when CMP0022
 is set to NEW.


  cmake_minimum_required(VERSION 2.8.12.1)

  project(foo)

  add_library(foo SHARED foo.cpp)
  add_library(bar SHARED foo.cpp)
  target_link_libraries(bar foo)

  export(TARGETS foo bar FILE myTargets.cmake)

It is not obvious to the user that they are causing their downstreams to 
depend on CMake 2.8.12. There was no warning about it (because there is no 
bug in the code), no build error and no export error.

By populating INTERFACE_LINK_LIBRARIES instead, the result would be that 
downstreams require 2.8.12. If that's what you want I can change this when 
the policy is NEW. I think that's fine. If they care about their 
downstreams, they'd test or examine their export files when they bump their 
cmake version requirement.

Or maybe I can export both INTERFACE_LINK_LIBRARIES and 
IMPORTED_LINK_INTERFACE_LIBRARIES. But then, when could we ever not export 
IMPORTED_LINK_INTERFACE_LIBRARIES? As this case is mostly just resulting 
from a 'very ingrained' pattern of not making the link interface explicit, I 
don't think it matters if we always export IMPORTED_LINK_INTERFACE_LIBRARIES 
in this case. We stop exporting it when the user makes their link interface 
explicit. However, if they do the migration to 2.8.12 (no output from cmake) 
and then later make their link interface explicit (no output from cmake), 
then downstream now require 2.8.12. I think that's fine. If they care about 
their downstreams they need to test or examine their export files in this 
case too.

Or we could make it a CMP0022-NEW-error to export a target which has link 
dependencies and no explicit link interface and 
EXPORT_LINK_INTERFACE_LIBRARIES is not used. I think this is still my 
preference. Everything else is very messy. 

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-10-30 Thread Brad King 
On 10/30/2013 09:01 AM, Stephen Kelly wrote:
 Brad King wrote:
 
 When CMP0022 is NEW the INTERFACE_LINK_LIBRARIES is always the link
 interface without the link implementation fallback, but the tll plain
 signature does not populate INTERFACE_LINK_LIBRARIES either.  This is
 not correct.
 
 I actually prefer this behavior, but as it's not backward compatible, 
 something has to be done about it.

The purpose of CMP0023 was that in combination with CMP0022 everyone
can switch over to the keyword signatures and then get the generally
preferred behavior.  The historical behavior of the plain tll signature
is too deeply ingrained in projects to ever change.

 I've implemented this in handle-only-plain-tll in my clone, but made the 
 policy control the behavior. If that's fine I can add tests for that.

If I'm reading that correctly the behavior will still be changed
when CMP0022 is set to new.  The only difference is now you warn
when the policy is not set.  This will warn in the basic use case
that has been used in examples since the beginning of CMake.

We really need to just silently use the link implementation as
the link interface as has always been done when only the plain tll
signature is used.  New projects can use the keyword signatures
which always set the link interface explicitly.

The only question is whether cmTarget's logic should fall back to the
link implementation when only the plain tll signature is used even
if INTERFACE_LINK_LIBRARIES is not set, or tll's plain signature
should maintain INTERFACE_LINK_LIBRARIES until another signature
is used to set it explicitly.  I prefer the latter because it means
we can still say that when CMP0022 is NEW the INTERFACE_LINK_LIBRARIES
always holds the link interface and it can be checked with get_property
at any time for debugging.  Wasn't that one of your goals?

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-10-30 Thread Stephen Kelly 
Brad King wrote:

 On 10/30/2013 09:01 AM, Stephen Kelly wrote:
 Brad King wrote:
 
 When CMP0022 is NEW the INTERFACE_LINK_LIBRARIES is always the link
 interface without the link implementation fallback, but the tll plain
 signature does not populate INTERFACE_LINK_LIBRARIES either.  This is
 not correct.
 
 I actually prefer this behavior, but as it's not backward compatible,
 something has to be done about it.
 
 The purpose of CMP0023 was that in combination with CMP0022 everyone
 can switch over to the keyword signatures and then get the generally
 preferred behavior.  The historical behavior of the plain tll signature
 is too deeply ingrained in projects to ever change.

Ok.

 
 I've implemented this in handle-only-plain-tll in my clone, but made the
 policy control the behavior. If that's fine I can add tests for that.
 
 If I'm reading that correctly the behavior will still be changed
 when CMP0022 is set to new.  The only difference is now you warn
 when the policy is not set.  This will warn in the basic use case
 that has been used in examples since the beginning of CMake.
 
 We really need to just silently use the link implementation as
 the link interface as has always been done when only the plain tll
 signature is used.  New projects can use the keyword signatures
 which always set the link interface explicitly.

Ok. I've updated my topic to remove the policy logic.

 
 The only question is whether cmTarget's logic should fall back to the
 link implementation when only the plain tll signature is used even
 if INTERFACE_LINK_LIBRARIES is not set, or tll's plain signature
 should maintain INTERFACE_LINK_LIBRARIES until another signature
 is used to set it explicitly.

Right. Currently it is the former. I'm not certain the latter is possible 
while keeping everything else working. I can look into it again though.

 I prefer the latter because it means
 we can still say that when CMP0022 is NEW the INTERFACE_LINK_LIBRARIES
 always holds the link interface and it can be checked with get_property
 at any time for debugging.  Wasn't that one of your goals?

I don't recall. I have a wip topic adding LINK_LIBRARIES support to 
CMAKE_DEBUG_TARGET_PROPERTIES. It's not really the same but a bigger goal 
for me than this I think.

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2013-10-30 Thread Brad King 
On 10/30/2013 10:30 AM, Stephen Kelly wrote:
 Ok. I've updated my topic to remove the policy logic.

Thanks.  Some comments:

+  onlyPlain = false;
+  break;

Can't that just be return false now?

Also please add the corresponding test case and base the topic
on v2.8.12~2 so we can merge it for 2.8.12.1 after it passes
in 'next'.

Thanks,
-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers