${OPENCV_MODULE_${the_module}_DEPS} incorrectly populated (Bug #1909)

Added by Del Thanil almost 13 years ago. Updated almost 13 years ago.

Status:Cancelled Start date:2012-05-09
Priority:Normal Due date:
Assignee:Andrey Kamaev % Done:

0%
Category:build/install
Target version:2.4.1 Estimated time:1.00 hour
Affected version: Operating System:
Difficulty: HW Platform:
Pull request:

Description

OPENCV_MODULE_${the_module}_DEPS should contain all a module's dependencies, and dependencies are transitive, however:
OPENCV_MODULE_opencv_calib3d_DEPS contains opencv_features2d
and OPENCV_MODULE_opencv_features2d_DEPS contains opencv_highgui
BUT OPENCV_MODULE_opencv_calib3d_DEPS does NOT contain opencv_highgui

the same happens with opencv_stitching > opencv_features2d > opencv_highgui

Associated revisions

Revision f9190cc6
Added by Andrey Pavlenko over 11 years ago

Merge pull request #1909 from alalek:ocl_tapi_perf

History

#1
Updated by Del Thanil almost 13 years ago

To be more precise, dependencies aren't necessarily transitive (my bad) but calib3d and stitching explicitly depend on highgui (on Mac OS X, an `otool -L libopencv_calib3d.dylib` contains a link to libopencv_highgui.dylib).

#2
Updated by Del Thanil almost 13 years ago

Again, to add precision, I forgot to mention that I was referring to the CMake files of the OpenCV project. The bug only creates problems when creating custom cmake builds.

#3
Updated by Andrey Kamaev almost 13 years ago

  1. Optional module dependencies are not transitive by design.
  2. opencv_calib3d and opencv_stitching modules do not really use any code from opencv_highgui.
  3. Dependencies shown by otool are created by CMake default link rules. Normally CMake puts all inherited dependencies to the link command for inter-project dependencies.

If current behavior interferes with your work then, please, create a new feature request with clear rationale.

  • Status changed from Open to Cancelled
  • Category set to build/install
  • Assignee set to Andrey Kamaev

#4
Updated by Del Thanil almost 13 years ago

I've done some more research and this is a CMake bug:

If target A depends on a shared library B and B depends on a shared library C, then CMake will create linker directives to link A to both B and C, when it should only link A to B.

Sorry for improperly posting the bug here, I managed to find a workaround in my particular case.

Also available in: Atom PDF