[MacPorts] #48288: CMake generating broken Xcode projects when using OpenCV

[MacPorts]

#48288: CMake generating broken Xcode projects when using OpenCV
-----------------------------------+--------------------------------
  Reporter:  christian.richardt@…  |      Owner:  macports-tickets@…
      Type:  defect                |     Status:  new
  Priority:  Normal                |  Milestone:
 Component:  ports                 |    Version:  2.3.3
Resolution:                        |   Keywords:
      Port:  opencv cmake          |
-----------------------------------+--------------------------------

Comment (by ryandesign@…):

 Replying to [comment:4 christian.richardt@…]:
 > The problem in `FRAMEWORK_SEARCH_PATHS = (//System/Library/Frameworks,
 );` indeed appears to be the double slash. Deleting one of the slashes
 manually (in all instances) fixes the Xcode project. Seems like Xcode is a
 little fragile in that respect, and maybe it's a a regression in Xcode.

 That's unfortunate. Arguably, Xcode is correct to complain about double
 slashes because they are not canonical. But we did encounter problems in
 MacPorts before adopting our current strategy of using "/" as the SDK path
 when no SDK path need otherwise be specified. It is possible that newer
 versions of cmake have made this unnecessary, but if not, then we need to
 keep it, or find another workaround.

 I do see that [http://www.cmake.org/Bug/view.php?id=15040 a change went
 into cmake 3.1] to allow SDK "/" to be treated as the current OS X
 version. Not sure what we were doing before that; maybe we were patching
 cmake.

 We do have a long history of changing this behavior in the cmake
 portgroup, with good intentions, but with the consequence of inadvertently
 breaking some ports while fixing others, so we need to tread very
 carefully. For further reading on past issues, see Joshua's list of
 tickets and revisions in comment:ticket:44125:12.

 > {{{
 > > Libs.private: -L/opt/local/lib -lQtOpenGL -lQtGui -lQtTest -lQtCore
 -lpng -ltiff -ljasper -ljpeg -lImath -lIlmImf -lIex -lHalf -lIlmThread
 -lavcodec -lavformat -lavutil -lswscale -lavresample -lz -lbz2
 -l-framework VideoDecodeAcceleration -l-framework QTKit -l-framework
 QuartzCore -l-framework AppKit -L//System/Library/Frameworks -lAGL
 -lOpenGL
 > }}}

 `-L//System/Library/Frameworks` is wrong in any case, because
 `//System/Library/Frameworks` is a directory that contains frameworks, not
 libraries, so the correct flag would be `-F//System/Library/Frameworks`.


 > I tracked down the source to the following: if OpenCV is configured
 `WITH_QT`, and Qt is found,
 [https://github.com/Itseez/opencv/blob/b46719b0931b256ab68d5f833b8fadd83737ddd1/cmake/OpenCVFindLibsGUI.cmake#L73
 OpenCVFindLibsGUI.cmake] also adds `${OPENGL_LIBRARIES}` (AGL and OpenGL)
 to `OPENCV_LINKER_LIBS`. This appears to be the step that produces the
 broken paths. For some reason, the SDK path component is missing, which I
 do get if I do
 > {{{
 > find_package(OpenGL REQUIRED)
 > message(STATUS ${OPENGL_LIBRARIES})
 > }}}
 > in a test project:
 > {{{
 >
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/AGL.framework
 >
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/OpenGL.framework
 > }}}
 >
 > I don't understand why `find_package(OpenGL REQUIRED)` produces
 different paths when MacPort configures OpenCV than when I use it in my
 own project?

 The SDK path component is not missing under MacPorts; rather, when there
 is no particular need for an SDK, we specify (in the cmake 1.0 portgroup,
 as mentioned above) that the SDK path shall be "/", and everything else
 follows from that. The reason you see a difference in your own project is
 that you are presumably specifying the path to the 10.10 SDK, not "/".

 I do have an open proposal for MacPorts to always use the real SDK path,
 even when it is not needed: #41783. Although this seems to work well for
 me, and might solve this particular problem you're having (you could try
 it), it causes other problems, which is a reason why we haven't committed
 it yet, and might never do so.

 I'm not entirely sure it's correct for cmake to be prepending the SDK path
 to the other paths, like it's doing. In Xcode and other build systems, the
 SDK is a separate setting, not mixed directly with paths in other
 variables.

-- 
Ticket URL: <https://trac.macports.org/ticket/48288#comment:5>
MacPorts <https://www.macports.org/>
Ports system for OS X