[CMake] Fwd: Fwd: cpack DragNDrop on OSX 10.7

[Yngve Levinsen]

Dear Clinton and David,

Thanks for your replies. I did notice the COMPONENT discrepancy on my
other project, but I figured out now that I had misunderstood the
first time (or at least I think so). What I wrote then was something
along the lines of (which didn't work):
INSTALL(TARGETS ${mtargets}
  BUNDLE DESTINATION .
  RUNTIME DESTINATION bin
  LIBRARY DESTINATION lib
  ARCHIVE DESTINATION lib
 COMPONENT Runtime
)
What I just now realized worked was to do instead
INSTALL(TARGETS ${mtargets}
  BUNDLE DESTINATION . COMPONENT Runtime
  RUNTIME DESTINATION bin COMPONENT Runtime
  LIBRARY DESTINATION lib COMPONENT Libraries
  ARCHIVE DESTINATION lib COMPONENT Libraries
)
In other words, for every type of target, set the component. This now
works very well for the Mad-X project. I had also done some other
unnecessary complications with the COMPONENT stuff on the other
project, which cluttered things and hid my real problems I think.

>>> What libs does your bundle app depend on? Are they
>>> built into the app with full path names such that an tool -L analysis
>>> will work without any DIRS value?
Currently only X11, sometimes libgfortran (I think it depends on which
gfortran version you are using?). At least for this project, otool -L
solves it all. For my other project which I don't have in a public
place at the moment it looks like I have a bit more problems now (it
worked as well with my previous install). You might have given me a
good hint right there.

To both of you, thank you very much for your time and help!

Best Regards, and a Merry Christmas to everyone on the list,
Yngve

On 21 December 2011 00:33, David Cole <david.cole at kitware.com> wrote:
> Good catch, Clinton. I did not notice the COMPONENT discrepancy.
>
>
> On Tue, Dec 20, 2011 at 6:26 PM, Clinton Stimpson <clinton at elemtech.com> wrote:
>>
>> This doesn't look right:
>>
>> INSTALL(TARGETS ${mtargets}
>>  BUNDLE DESTINATION .
>>  RUNTIME DESTINATION bin
>>  LIBRARY DESTINATION lib
>>  ARCHIVE DESTINATION lib
>> )
>>
>> INSTALL(CODE "
>>  include(BundleUtilities)
>>  fixup_bundle(\"${APPS}\"   \"\"   \"${DIRS}\")
>>  " COMPONENT Runtime)
>>
>> The target and fixup of the target are in different components, so that can
>> cause problems at cpack time depending on your generator.
>>
>> Clint
>>
>> On Tuesday, December 20, 2011 04:13:35 pm David Cole wrote:
>>> You're doing this:
>>>
>>>   set(APPS "\${CMAKE_INSTALL_PREFIX}/madx${BINARY_POSTFIX}.app")  #
>>> paths to executables
>>>   set(DIRS "")
>>>
>>> Then this:
>>>
>>>   INSTALL(CODE "
>>>     include(BundleUtilities)
>>>     fixup_bundle(\"${APPS}\"   \"\"   \"${DIRS}\")
>>>     " COMPONENT Runtime)
>>>
>>> Which means that your install code (in cmake_install.cmake) will have
>>> something like this in it:
>>>
>>>     include(BundleUtilities)
>>>     fixup_bundle("${CMAKE_INSTALL_PREFIX}/madxXXX.app"   ""   "")
>>>
>>> CMAKE_INSTALL_PREFIX should evaluate to a directory underneath the
>>> _CPack_Packages directory, so that should be ok. But your DIRS
>>> variable is empty. What libs does your bundle app depend on? Are they
>>> built into the app with full path names such that an tool -L analysis
>>> will work without any DIRS value?
>>>
>>> Did you run something like "cpack -G DragNDrop --verbose" to see the
>>> full output of the make install step, and did it seem like
>>> fixup_bundle yielded any output in the --verbose stream...?
>>>
>>> Your code looks right, but maybe you need some DIRS for the fixup to
>>> work correctly...
>>>
>>>
>>> HTH,
>>> David