MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0016058CMakeCMakepublic2016-04-11 15:242016-06-10 14:21
ReporterAlex Ferrier 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformMacOSOSX El CapitanOS Version10.11.4
Product VersionCMake 3.5.1 
Target VersionFixed in Version 
Summary0016058: ImageMagick found from Command line but not from CMake GUI
DescriptionI am trying to configure the project Theia-SfM to compile with XCode on a Mac.

https://github.com/sweeneychris/TheiaSfM [^]

Using CMake 3.5.1 installed via Macports via XCode the package configures and builds fine once the appropriate dependencies are installed, e.g.

mkdir Build
cmake -G XCode ..

-- Generating done
-- Build files have been written to: /Users/alex/src/TheiaSfM/build
If using CMake GUI 3.5.1 downloaded from KitWare, and installed via applications, the same build fails to find ImageMagick. Output ends:

-- Found SuiteSparse 4.2.1
-- Check for ImageMagick
ImageMagick_EXECUTABLE_DIRImageMagick_EXECUTABLE_DIR-NOTFOUND
CMake Error at /Applications/CMake.app/Contents/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find ImageMagick (missing: ImageMagick_convert_EXECUTABLE
  ImageMagick_mogrify_EXECUTABLE ImageMagick_convert_EXECUTABLE
  ImageMagick_mogrify_EXECUTABLE)
ImageMagick is demonstrably installed (via macports) in /opt/local/bin.

Alexs-MacBook-Pro:TheiaSfM alex$ type -a mogrify
mogrify is /opt/local/bin/mogrify
Is there any obvious reason why identical versions of CMake would fail to find the same package? I'm assuming /opt/local is in my CMake GUI paths search paths, because further up it finds other dependencies there.

-- Found Google Flags: /opt/local/include in namespace: google
-- Check for Google Log
-- Found Google Logging: /opt/local/include
-- Check for Ceres
Steps To ReproduceSee description, download package and configure with command line (successful) and GUI (unsuccessful.) Presumably reproducible with other builds using imagemagick?
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-04-11 15:24Alex FerrierNew Issue
2016-04-11 15:31Brad KingNote Added: 0040837
2016-04-11 15:38Alex FerrierNote Added: 0040838
2016-04-11 15:53Brad KingNote Added: 0040839
2016-04-11 15:55Ben BoeckelNote Added: 0040840
2016-04-11 16:06Alex FerrierNote Added: 0040841
2016-04-11 16:17Brad KingNote Added: 0040842
2016-04-11 16:17Brad KingStatusnew => resolved
2016-04-11 16:17Brad KingResolutionopen => no change required
2016-06-10 14:21Kitware RobotNote Added: 0041196
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0040837)
Brad King   
2016-04-11 15:31   
> why identical versions of CMake would fail to find the same package?

If one was from upstream and one was from Macports then they may not be identical. It is possible that Macports is patching their version to find Macports-installed software that upstream does not know about.

To help distinguish the cases, try a command-line build using the upstream command-line tool:

 /Applications/CMake.app/Contents/usr/bin/cmake .. -G Xcode
(0040838)
Alex Ferrier   
2016-04-11 15:38   
Interestingly that appears to work (didn't need the /usr bit of the path to cmake executable.) I attached full output, but the generated XCodeProj is valid. Still not sure why GUI isn't working.


Alexs-MacBook-Pro:buildNonPort alex$ /Applications/CMake.app/Contents/bin/cmake -G Xcode ..
-- The C compiler identification is AppleClang 7.3.0.7030029
-- The CXX compiler identification is AppleClang 7.3.0.7030029
-- Check for working C compiler using: Xcode
-- Check for working C compiler using: Xcode -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler using: Xcode
-- Check for working CXX compiler using: Xcode -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Eigen: /usr/local/include/eigen3 (found suitable version "3.2.7", minimum required is "3.2.0")
-- Found Eigen version 3.2.7: /usr/local/include/eigen3
-- Performing Test HAVE_RETURN_TYPE_C_LINKAGE
-- Performing Test HAVE_RETURN_TYPE_C_LINKAGE - Success
-- No preference for use of exported gflags CMake configuration set, and no hints for include/library directories provided. Defaulting to preferring an installed/exported gflags CMake configuration if available.
-- Found installed version of gflags: /opt/local/lib/cmake/gflags
-- Detected broken gflags install in: /opt/local/lib/cmake/gflags, version: 2.1.2 <= 2.1.2 which defines gflags_LIBRARIES = gflags which is not an imported CMake target, see: https://github.com/gflags/gflags/issues/110. [^] Attempting to fix by detecting correct gflags target.
-- Found valid gflags target: gflags-shared, updating gflags_LIBRARIES.
-- Detected gflags version: 2.1.2
-- Found Gflags: /opt/local/include
-- Found Google Flags: /opt/local/include in namespace: google
-- Check for Google Log
-- Found Glog: /opt/local/include
-- Found Google Logging: /opt/local/include
-- Check for Ceres
-- Found required Ceres dependency: Eigen version 3.2.7 in /usr/local/include/eigen3
-- Found required Ceres dependency: Glog in /opt/local/include
-- Found Ceres version: 1.11.0 installed in: /opt/local
-- Found Ceres: /opt/local/include;/usr/local/include/eigen3;/opt/local/include
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- A library with BLAS API found.
-- Found AMD library: /opt/local/lib/libamd.dylib
-- Found AMD header in: /opt/local/include
-- Found CAMD library: /opt/local/lib/libcamd.dylib
-- Found CAMD header in: /opt/local/include
-- Found COLAMD library: /opt/local/lib/libcolamd.dylib
-- Found COLAMD header in: /opt/local/include
-- Found CCOLAMD library: /opt/local/lib/libccolamd.dylib
-- Found CCOLAMD header in: /opt/local/include
-- Found CHOLMOD library: /opt/local/lib/libcholmod.dylib
-- Found CHOLMOD header in: /opt/local/include
-- Found SuiteSparseQR library: /opt/local/lib/libspqr.dylib
-- Found SuiteSparseQR header in: /opt/local/include
-- Did not find Intel TBB library, assuming SuiteSparseQR was not compiled with TBB.
-- Found SuiteSparse_config library: /opt/local/lib/libsuitesparseconfig.dylib
-- Found SuiteSparse_config header in: /opt/local/include
-- Found METIS library: /opt/local/lib/libmetis.dylib.
-- Found SuiteSparse: TRUE (found version "4.2.1")
-- Found SuiteSparse 4.2.1
-- Found PythonInterp: /usr/bin/python (found version "2.7.10")
-- Found ZLIB: /opt/local/lib/libz.dylib (found version "1.2.8")
-- Found PNG: /opt/local/lib/libpng.dylib (found version "1.4.12")
-- Found JPEG: /opt/local/lib/libjpeg.dylib
-- Found TIFF: /opt/local/lib/libtiff.dylib (found version "4.0.3")
-- Check for ImageMagick
-- Found ImageMagick: /opt/local/bin/convert (found version "6.9.3-4")
-- Found ImageMagick:
-- A library with BLAS API found.
-- Performing Test COMPILER_HAS_CXX11_FLAG
-- Performing Test COMPILER_HAS_CXX11_FLAG - Success
-- CMAKE_CXX_FLAGS: -Qunused-arguments -mllvm -inline-threshold=600 -Wno-return-type-c-linkage -std=c++11 -stdlib=libc++
-- Found Eigen: /usr/local/include/eigen3 (found version "3.2.7")
-- Found Eigen version 3.2.7: /usr/local/include/eigen3
-- CMAKE_CXX_FLAGS: -Qunused-arguments -mllvm -inline-threshold=600 -Wno-return-type-c-linkage -std=c++11 -stdlib=libc++
-- Default Install prefix: /usr/local/
-- Found Eigen version 3.2.7: /usr/local/include/eigen3
-- Found installed version of gflags: /opt/local/lib/cmake/gflags
-- Detected broken gflags install in: /opt/local/lib/cmake/gflags, version: 2.1.2 <= 2.1.2 which defines gflags_LIBRARIES = gflags which is not an imported CMake target, see: https://github.com/gflags/gflags/issues/110. [^] Attempting to fix by detecting correct gflags target.
-- Found valid gflags target: gflags-shared, updating gflags_LIBRARIES.
-- Detected gflags version: 2.1.2
-- Check for Google ceres-solver
-- Found required Ceres dependency: Eigen version 3.2.7 in /usr/local/include/eigen3
-- Found required Ceres dependency: Glog in /opt/local/include
-- Found Ceres version: 1.11.0 installed in: /opt/local
-- Found Ceres headers in: /opt/local/include;/usr/local/include/eigen3;/opt/local/include;/opt/local/include;/usr/local/include/eigen3;/opt/local/include
-- A library with BLAS API found.
-- A library with BLAS API found.
-- A library with LAPACK API found.
-- Check for Optimo
-- Found optimo headers: /usr/local
-- No build type specified; defaulting to CMAKE_BUILD_TYPE=Release.
-- Performing Test HAVE_LTO_SUPPORT
-- Performing Test HAVE_LTO_SUPPORT - Success
-- Enabling link-time optimization (-flto)
-- Enabling link-time optimization (-flto)
-- Found OpenGL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework
-- Found GLUT: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/GLUT.framework
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/alex/src/TheiaSfM/buildNonPort
(0040839)
Brad King   
2016-04-11 15:53   
Does macports update the command-line prompt environment (via .bashrc or something)? If so your PATH may be different between the command line and the GUI. Add

  message("PATH='$ENV{PATH}'")

to your project CMakeLists.txt file just before the find_package call temporarily. Look at the output from both environments to compare them.
(0040840)
Ben Boeckel   
2016-04-11 15:55   
Yeah, we ran into this on 10.11 over here. PATH cannot be modified for the GUI app, so things like Ninja cannot be found from the GUI (at least in a from-scratch build).
(0040841)
Alex Ferrier   
2016-04-11 16:06   
Yep, as you guess, they're completely different:

GUI:
DebugLog PATH='/usr/bin:/bin:/usr/sbin:/sbin'

Console:
DebugLog PATH='/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/alex/NVPACK/apache-ant-1.8.2/bin:/Users/alex/NVPACK/gradle-2.2.1/bin:/Users/alex/NVPACK/android-sdk-macosx/tools:/Users/alex/NVPACK/android-sdk-macosx/platform-tools:/Users/alex/NVPACK/android-sdk-macosx/build-tools:/Users/alex/NVPACK/android-sdk-macosx/extras/android/support-tools:/Users/alex/NVPACK/android-ndk-r10e'

Unurprisingly, the console version matches a direct log of my PATH var.

Alexs-MacBook-Pro:buildNonPort alex$ echo "$PATH"
/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/alex/NVPACK/apache-ant-1.8.2/bin:/Users/alex/NVPACK/gradle-2.2.1/bin:/Users/alex/NVPACK/android-sdk-macosx/tools:/Users/alex/NVPACK/android-sdk-macosx/platform-tools:/Users/alex/NVPACK/android-sdk-macosx/build-tools:/Users/alex/NVPACK/android-sdk-macosx/extras/android/support-tools:/Users/alex/NVPACK/android-ndk-r10e

As opposed to a clean image of a Mac (which I also have here), which doesn't have the /opt/local paths added to bash search paths. (It looks identical to system defaults, which CMakeGUI is reading.)

So, it seems this is not as such a bug with CMake, as a warning that Macports and any gui app (not just CMakeGui) will not know about each other unless you modify system defaults.

Since we build on both OSX and Windows, and Macports adds more unpredictability than it solves, we are going to stop using Macports, and start downloading explicit versions of dependencies.
(0040842)
Brad King   
2016-04-11 16:17   
Re 0016058:0040841: Okay, thanks for reporting back. I'll mark this as resolved on the CMake side.
(0041196)
Kitware Robot   
2016-06-10 14:21   
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.