#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/b46719b0931b256ab68d5f833b8fadd83737dd... 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