[CMake] CMake 2.8.3 built on OS X crashes on Startup.

[Clinton Stimpson]

I can't reproduce the problem using the current cmake source from git.

Clint

On Wednesday, January 05, 2011 08:05:43 am Michael Jackson wrote:
> Reopened the bug because this is _still_ an issue with CMake 2.8.3. Just
> tried to configure, build and install and got the same crash.
> ___________________________________________________________
> Mike Jackson                      www.bluequartz.net
> Principal Software Engineer       mike.jackson at bluequartz.net
> BlueQuartz Software               Dayton, Ohio
> 
> On Dec 5, 2009, at 5:05 PM, Mike Jackson wrote:
> > Reported as bug number 10000 <http://paraview.org/Bug/view.php?id=10000>
> > 
> > Hey, do I get some sort of Cookie or something for having bug number
> > 10,000? At least it will be easy to remember the bug number.
> > 
> > _________________________________________________________
> > Mike Jackson                  mike.jackson at bluequartz.net
> > 
> > On Sat, Dec 5, 2009 at 4:59 PM, Mike Jackson
> > 
> > <mike.jackson at bluequartz.net> wrote:
> >> Sorry No Patch but here is what needs to be inserted into
> >> $CMAKE_SOURCE/Source/QtDialog/CMakeLists.txt.
> >> 
> >> I'll put some context around it for David or Bill to more easily find the 
place:
> >>  IF(APPLE)
> >>  
> >>    SET(CMAKE_POSTFLIGHT_SCRIPT
> >>    
> >>      "${CMake_BINARY_DIR}/Source/QtDialog/postflight.sh")
> >>    
> >>    SET(CMAKE_POSTUPGRADE_SCRIPT
> >>    
> >>      "${CMake_BINARY_DIR}/Source/QtDialog/postupgrade.sh")
> >>    
> >>    configure_file("${CMake_SOURCE_DIR}/Source/QtDialog/postflight.sh.in"
> >>    
> >>      "${CMake_BINARY_DIR}/Source/QtDialog/postflight.sh")
> >>    
> >>    configure_file("${CMake_SOURCE_DIR}/Source/QtDialog/postupgrade.sh.in
> >>    "
> >>    
> >>      "${CMake_BINARY_DIR}/Source/QtDialog/postupgrade.sh")
> >>    
> >>    INSTALL(CODE "execute_process(COMMAND ln -s
> >> 
> >> \"../MacOS/${CMAKE_BUNDLE_NAME}\" cmake-gui
> >> 
> >>                  WORKING_DIRECTORY
> >> 
> >> \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/bin)")
> >> 
> >>    INSTALL(CODE "set(input_file
> >>    
> >>       \"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/MacOS/${CMAKE_BUNDLE_NAME
> >>       }\")")
> >>    
> >>    INSTALL(SCRIPT
> >> 
> >> "${CMake_SOURCE_DIR}/Source/QtDialog/CMakeIngestOSXBundleLibraries.cmake
> >> ")
> >> 
> >>    IF (QT_MAC_USE_COCOA)
> >>    
> >>        INSTALL(CODE "execute_process(COMMAND /usr/bin/touch
> >> 
> >> \"../Resources/qt.conf\"
> >> 
> >>                         WORKING_DIRECTORY
> >> 
> >> \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/bin)")
> >> 
> >>        INSTALL(CODE "execute_process(COMMAND cp -R
> >> 
> >> \"${QT_LIBRARY_DIR}/QtGui.framework/Resources/qt_menu.nib\"
> >> \"../Resources/\"
> >> 
> >>         WORKING_DIRECTORY \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/bin)")
> >>    
> >>    ENDIF(QT_MAC_USE_COCOA)
> >>  
> >>  ENDIF(APPLE)
> >> 
> >> Hopefully that will get committed into CVS HEAD  asap as this probably
> >> is getting pretty important with Snow Leopard defaulting to 64 bit
> >> compiles, which forces Qt to be 64 bit, which forces Cocoa to be used,
> >> which forces this patch..
> >> 
> >> Thanks
> >> _________________________________________________________
> >> Mike Jackson                  mike.jackson at bluequartz.net
> >> 
> >> On Sat, Dec 5, 2009 at 11:12 AM, Clinton Stimpson <clinton at elemtech.com> 
wrote:
> >>>> It would be nice to have a function allowing one to override/extend
> >>>> the default choice (which AFAIK is determined by asking otool about
> >>>> link-dependencies). Perhaps something like this:
> >>>> 
> >>>> set_external_framework_properties(
> >>>> 
> >>>>  ${QT_QTGUI_LIBRARY} PROPERTIES
> >>>>  REQUIRE Resources/qt_menu.nib DESTINATION <APP_BUNDLE>/Resources
> >>>>  REQUIRE Versions/Current/Headers DESTINATION <FRAMEWORK>
> >>>>  )
> >>>> 
> >>>> which sets a few directory properties which then are used by
> >>>> fixup_bundle_item from the BundleUtilities for customizing the copied
> >>>> framework. The <APP_BUNDLE> and <FRAMEWORK> strings could resolve to
> >>>> the application-bundle being fixed up and the framework bundle
> >>>> directory, respectively.
> >>> 
> >>> I'd prefer a default behavior that would work most of the time.
> >>> I realize people can stuff whatever they want into a Framework, but
> >>> some things are standard, and Resources is one of the standard ones,
> >>> so I think that one should be fixed without having to make any changes
> >>> to a user's CMakeLists.txt file.
> >>> 
> >>> Also, some frameworks that BundleUtilities would copy aren't
> >>> necessarily known by cmake during link time, nor specified in any
> >>> CMakeLists.txt file.
> >>> 
> >>> Clint
> 
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake