MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015971CMakeCMakepublic2016-02-11 14:522016-06-10 14:31
ReporterMarcus D. Hanwell 
Assigned ToRobert Maynard 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSLinuxOS VersionArch
Product VersionCMake 3.4.3 
Target VersionFixed in Version 
Summary0015971: CMake alias resolution appears to be inconsistently applied
DescriptionThe Tomviz project extends ParaView, and uses a number of imported targets. Some of these come from VTK, others come from ParaView. When migrating to Qt 5 we hit a strange bug where the Qt 5 interface library aliases were not getting expanded unless we explicitly added them to the target_link_libraries line. Printing them out all the libraries were found, but the link line had -lQt5::Help etc. It looks like the Qt5::Widgets alias was the only one resolved.

If I switch the order of finding ParaView and finding Qt5 around everything worked. If I find ParaView first, then Qt 5 it fails at linking, unless I add all of the libraries to the target_link_libraries, in which case it resolved them and the link step succeeded. This seems very inconsistent to me, perhaps it is intended for for reason due to the order in which you resolve aliases? It took something that was fairly resilient to call order previously and made it more brittle in our project.
Steps To Reproduce
Additional Informationhttps://github.com/OpenChemistry/tomviz/commit/525336b3e94170ec2e2c463894de034d539898cc [^] shows the commit I am hoping will make this consistent everywhere. If aliases make this strict ordering necessary that was not evident to me.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-02-11 14:52Marcus D. HanwellNew Issue
2016-02-11 14:52Marcus D. HanwellStatusnew => assigned
2016-02-11 14:52Marcus D. HanwellAssigned To => Robert Maynard
2016-02-11 15:27Robert MaynardNote Added: 0040474
2016-02-17 17:07Stephen KellyNote Added: 0040503
2016-02-18 16:33Marcus D. HanwellNote Added: 0040507
2016-02-18 16:36Marcus D. HanwellNote Added: 0040508
2016-02-19 04:25Stephen KellyNote Added: 0040511
2016-02-19 15:11Marcus D. HanwellNote Added: 0040516
2016-02-19 15:46Stephen KellyNote Added: 0040517
2016-02-24 14:12Brad KingNote Added: 0040537
2016-02-24 14:15Brad KingNote Added: 0040538
2016-02-24 14:31Brad KingNote Added: 0040539
2016-06-10 14:29Kitware RobotNote Added: 0042939
2016-06-10 14:29Kitware RobotStatusassigned => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0040474)
Robert Maynard   
2016-02-11 15:27   
It should be noted that ParaView invokes VTK's config which calls find_package(Qt5 COMPONENTS ... ) where the components are a subset of the components that TomViz and ParaView require.

After the VTK find_package(Qt5), all calls to find more COMPONENTS fail to update the resolution for imported targets that already exist.

Here is a step by step breakdown:

1. VTK find_package(Qt5 COMPONENTS Widgets)
2. Import ParaView and VTK targets
3. Imported targets that use Qt::Widget as an INTERFACE_LIBRARY are resolved, all other Qt import targets stays as "Qt::X"
4. Call target_link_libraries where you link to an imported ParaView target
5. Get a link error about "-lQt:X"
(0040503)
Stephen Kelly   
2016-02-17 17:07   
As far as I understand, no config package should call find_package(COMPONENTS)

 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/15330 [^]
(0040507)
Marcus D. Hanwell   
2016-02-18 16:33   
Even if that is the case, it seems highly unpredictable to design CMake's alias resolution to pre-cache some results, but not others. This was a weird and subtle issue, and I would hope that CMake would resolve aliases at target_link_library time. Is this an intended caching behavior?
(0040508)
Marcus D. Hanwell   
2016-02-18 16:36   
We have several projects that call find_package more than once, in different scopes, as they depend on different components. When developing projects we often want to find the relevant components for that target in that scope, and then find additional components for more dependent targets. I think we have done this with Boost and Qt dependencies in the past, and as a user I expect that to work reliably (and it was working fine with Qt 4 in the case of Tomviz).
(0040511)
Stephen Kelly   
2016-02-19 04:25   
I'm afraid I don't understand. There is so much incorrectness in phrases like 'Qt 5 interface library aliases' and 'Qt::Widget as an INTERFACE_LIBRARY' that I don't understand this bug report and I find it hard to read.

I suggest you create an http://sscce.org/ [^] .

No matter how much you, as a user, expect multiple find_package in different scopes to work reliably, that's not going to make it so. As far as I know there are lots of reasons it is not reliable. Also, a user might expect multiple find_package in the same scope (as with transitive package dependencies) to be 'reliable'. As far as I know it is not.

Someone would need to think that through and figure it out, find out what it means for cache variables etc, find out how COMPONENTS fit, find out whether transitive package dependencies fit etc etc. Find out what it already true and what the constraints are, then perhaps extend the documentation if you discover something interesting.
(0040516)
Marcus D. Hanwell   
2016-02-19 15:11   
OK, this is all the time I have for this, it looks a lot like a regression to me and it is clear you do not agree, you have all the details I have time to give. Rob, if you have time please follow up. I have a workaround for this issue, and can move forward. Please feel free to make your own SSCCE, or not.
(0040517)
Stephen Kelly   
2016-02-19 15:46   
I don't 'not agree'. I just don't understand what you're describing. That's where an sscce helps.
(0040537)
Brad King   
2016-02-24 14:12   
After talking to Robert I think this is simply a case of constructing an imported target in a subdirectory and then passing the name of the imported target as a string value to another directory where it is used in target_link_libraries. The imported target is available only in the original directory and its subdirectories and so it is not in scope for the latter target_link_libraries call.

This is user error and not a bug in CMake.

This happens as follows:

1. A VTK module calls find_package(Qt5 ...) in its CMakeLists.txt file
   This imports some Qt5::X libraries into the local scope. Using them
   with target_link_libraries works in that directory.

2. The VTK module publishes the Qt5::X library in its vtkSomeMod_LIBRARIES
   variable in its module information file.

3. Another module uses the first one and evaluates ${vtkSomeMod_LIBRARIES}
   in a call to target_link_libraries (inside module macros).

4. In the scope of the latter call to target_link_libraries the imported
   targets it names are not visible because they were only imported in
   the scope of the original module directory.

The problem is in interaction between imported target scopes and the VTK module macro usage requirement infrastructure. One fix is to never list Qt5::X libraries in the public list of library dependencies of any module. They should be used only as private implementation details. Another solution is to move any call to find_package(Qt5 ...) into a vtk-module-init.cmake file next to the module.cmake file in the module. This will make the imported targets available from the top level and therefore visible everywhere.
(0040538)
Brad King   
2016-02-24 14:15   
Re 0015971:0040537: For reference, the reason this did not happen with Qt4 is because we were not using any imported targets and instead just passing the full paths to the library files around.
(0040539)
Brad King   
2016-02-24 14:31   
Re 0015971:0040511:

> No matter how much you, as a user, expect multiple find_package in different
> scopes to work reliably, that's not going to make it so. As far as I know
> there are lots of reasons it is not reliable. Also, a user might expect
> multiple find_package in the same scope (as with transitive package
> dependencies) to be 'reliable'. As far as I know it is not.

We've regularly done this for years. It may not be compatible with find_dependency or FeatureSummary though.

The results of find_package (in principle) are always provided as normal (non-cached) CMake variables. Therefore after

    find_package(Foo COMPONENTS C1 C2)

it is well-defined to say that Foo_FOUND is true if C1 and C2 were. Later one can have

    find_package(Foo COMPONENTS C3 C4)

and it is now well-defined to say that Foo_FOUND is true if C3 and C4 were. Code after each call can depend on such values.

The fact that some cache entries associated with each component may overlap between these two calls is incidental.
(0042939)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.