View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014512CMakeCMakepublic2013-10-25 11:352014-06-02 08:37
ReporterClinton Stimpson 
Assigned ToStephen Kelly 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0014512: cmp0022 does not warn
DescriptionUsing cmake 2.8.12 does not give a warning if the target property LINK_INTERFACE_LIBRARIES is used with export().
Steps To Reproduce
touch foo.cpp
touch bar.cpp

use the following for CMakeLists.txt:

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 "")
export(TARGETS bar foo FILE ${CMAKE_CURRENT_BINARY_DIR}/bar-export.cmake)


run cmake 2.8.12 on that, and there is no warning which is incorrect.

Change to
cmake_minimum_required(VERSION 2.8.12)
and there is an error, which is correct.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0034264)
Stephen Kelly (developer)
2013-10-27 06:04

This is pretty much the same issue as

 http://thread.gmane.org/gmane.comp.kde.devel.frameworks/6456 [^]

This feature was discussed in this thread:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6767/focus=7202 [^]

I think that the decision was to not warn in this case because there is nothing that can be done in response to the warning. The user can not use the EXPORT_LINK_INTERFACE_LIBRARIES argument to export(), because it doesn't exist before 2.8.12.

I guess users maybe could be advised to set INTERFACE_LINK_LIBRARIES (and not LINK_INTERFACE_LIBRARIES) to empty conditionally based on the minimum CMake version, if the policy is WARN.

Clinton, what kind of warning would you expect?
(0034281)
Clinton Stimpson (developer)
2013-10-29 08:53

Maybe that should be the advice. When I run CMake, I get this error:
  Target "foo" has policy CMP0022 enabled, but also has old-style
  LINK_INTERFACE_LIBRARIES properties populated, but it was exported without
  the EXPORT_LINK_INTERFACE_LIBRARIES to export the old-style properties

which tells me the newly expected EXPORT_LINK_INTERFACE_LIBRARIES is not set to help an old property keeps working. So I take that to mean that I now need to set it to fix my problem.

But then I read cmake --help-policy CMP0022, and it appears I get different advice, that is, I should be setting INTERFACE_LINK_LIBRARIES instead.

Perhaps the error message and policy help need improved so they can be reconciled.

Eventually, I think I'll end up using the PUBLIC/PRIVATE keywords in target_link_libraries() (maybe this can be mentioned as an alternative in the policy help).

But for now, I set the policy to old since I want 2.8.12 as a minimum version on Mac OS X only.
(0034283)
Clinton Stimpson (developer)
2013-10-29 09:16

And I would like the warning to say the same thing as the error. And both of those consistent with the policy help.
(0034285)
Stephen Kelly (developer)
2013-10-29 11:54

> But then I read cmake --help-policy CMP0022, and it appears I get different
> advice, that is, I should be setting INTERFACE_LINK_LIBRARIES instead.

It also says this:

> A new option to the install(EXPORT) and export commands
> allows export of the old-style properties for compatibility with
> downstream users of CMake versions older than 2.8.12.

which is a reference to EXPORT_LINK_INTERFACE_LIBRARIES, though it is not mentioned by name. Is that what is not clear?

Usually with policies, we're pointing out code that is buggy even if the user is using an older cmake version. We can advise them to change the code. In this case, we can't advise them to use INTERFACE_LINK_LIBRARIES or EXPORT_LINK_INTERFACE_LIBRARIES in a warning if they don't have 2.8.12 as their minimum requirement (In which case an error is reported already).

Brad, any input on this?
(0034286)
Clinton Stimpson (developer)
2013-10-29 12:05

Other cases may be buggy, but I don't consider my code buggy.
Wasn't it recommended in older versions of CMake to use LINK_INTERFACE_LIBRARIES to control the public dependencies? I think it used to be the only way to control it.

But now that is old. The confusion is that it wasn't clear to me what the problem actually was and why, and there was no clear path forward. The error says one thing, the policy help says another. That is why I'm dealing with it later and setting it to old for now.
(0034287)
Stephen Kelly (developer)
2013-10-29 13:09

Ok.

To be clear. I never said your code was buggy. I said the opposite, which is what makes this case difficult.
(0034288)
Clinton Stimpson (developer)
2013-10-29 14:58

Here's another related one where minimum version is 2.8 and new syntax is used:

cmake_minimum_required(VERSION 2.8)

add_library(foo SHARED foo.cpp)
add_library(foo2 SHARED foo2.cpp)

target_link_libraries(foo2 foo)
set_target_properties(foo2 PROPERTIES INTERFACE_LINK_LIBRARIES "")

add_executable(app app.cpp)
target_link_libraries(app foo2)


It gives the warning:
  Target "foo2" has a INTERFACE_LINK_LIBRARIES property which differs from
  its LINK_INTERFACE_LIBRARIES properties.

  INTERFACE_LINK_LIBRARIES:

  LINK_INTERFACE_LIBRARIES:
    (empty)

That doesn't make sense because I never set the LINK_INTERFACE_LIBRARIES property.
(0034290)
Stephen Kelly (developer)
2013-10-29 17:02

As I wrote in the comment above:

> In this case, we can't advise them to use INTERFACE_LINK_LIBRARIES

The LINK_INTERFACE_LIBRARIES property is populated because you don't set CMP0022 to NEW.
(0034292)
Brad King (manager)
2013-10-30 09:34

In the original example in the description I see no reason that it should warn. The code works as it always did and the exported results are the same with 2.8.11 or 2.8.12, no?

A policy warning is for when the newer CMake wants to do something different than the older CMake with the same code but can't because the project has no code that tells CMake it is aware of the newer preference (e.g. policy setting). Once a project has been modified with cmake_minimum_required at least the newer CMake then we know the project is aware of the new preferred behavior.

By upping the min req version to 2.8.12 you are telling CMake you are okay with preferred behavior as of that level. In this case that is an error message. As the developer bumping the min req version it is up to you to make it work.
(0034293)
Clinton Stimpson (developer)
2013-10-30 10:20

Oh, OK. So the difference from what I've seen before is that it kept the old behavior so there was no need to warn.
(0034294)
Brad King (manager)
2013-10-30 10:27

Re 0014512:0034293: Yes, exactly.
(0034385)
Brad King (manager)
2013-11-04 11:36

Additional discussion here:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8479 [^]
(0036000)
Robert Maynard (manager)
2014-06-02 08:37

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2013-10-25 11:35 Clinton Stimpson New Issue
2013-10-25 11:36 Brad King Assigned To => Stephen Kelly
2013-10-25 11:36 Brad King Status new => assigned
2013-10-27 06:04 Stephen Kelly Note Added: 0034264
2013-10-29 08:53 Clinton Stimpson Note Added: 0034281
2013-10-29 09:16 Clinton Stimpson Note Added: 0034283
2013-10-29 11:54 Stephen Kelly Note Added: 0034285
2013-10-29 12:05 Clinton Stimpson Note Added: 0034286
2013-10-29 13:09 Stephen Kelly Note Added: 0034287
2013-10-29 14:58 Clinton Stimpson Note Added: 0034288
2013-10-29 17:02 Stephen Kelly Note Added: 0034290
2013-10-30 09:34 Brad King Note Added: 0034292
2013-10-30 10:20 Clinton Stimpson Note Added: 0034293
2013-10-30 10:27 Brad King Note Added: 0034294
2013-10-30 12:47 Stephen Kelly Status assigned => resolved
2013-10-30 12:47 Stephen Kelly Resolution open => no change required
2013-11-04 11:36 Brad King Note Added: 0034385
2014-06-02 08:37 Robert Maynard Note Added: 0036000
2014-06-02 08:37 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team