MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009744CMakeModulespublic2009-10-20 13:192010-11-09 22:57
ReporterClinton Stimpson 
Assigned ToDavid Cole 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionCMake 2.8.3Fixed in VersionCMake 2.8.3 
Summary0009744: BundleUtilities making extra copies of plugins
DescriptionExtra copies of plugins were incorrectly being made and put in the bin/ folder. On the Mac, it led to fixing up the wrong copy. So some Qt apps on Mac that use plugins don't work right.

Just setting the copy flag = 0 as is done for executables fixes the problem.


Index: BundleUtilities.cmake
===================================================================
--- BundleUtilities.cmake (revision 41975)
+++ BundleUtilities.cmake (working copy)
@@ -351,7 +351,7 @@
     # but that do not show up in otool -L output...)
     #
     foreach(lib ${libs})
- set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 1)
+ set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0)

       set(prereqs "")
       get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}")
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0010417closed David Cole BundleUtilities/GetPrerequisites not doing bundleutilities example correctly 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-10-20 13:19Clinton StimpsonNew Issue
2009-10-20 13:33Bill HoffmanStatusnew => assigned
2009-10-20 13:33Bill HoffmanAssigned To => David Cole
2009-12-21 15:27David ColeNote Added: 0018964
2009-12-21 15:38Clinton StimpsonNote Added: 0018965
2009-12-21 15:41Clinton StimpsonNote Added: 0018967
2010-04-16 10:25Clinton StimpsonNote Added: 0020215
2010-08-05 17:28Clinton StimpsonRelationship addedparent of 0010417
2010-08-12 09:15Mike McQuaidNote Added: 0021731
2010-08-18 04:55Mike McQuaidNote Added: 0021799
2010-08-31 17:57David ColeTarget Version => CMake 2.8.3
2010-09-07 22:29David ColeNote Added: 0022121
2010-09-07 22:29David ColeStatusassigned => resolved
2010-09-07 22:29David ColeResolutionopen => fixed
2010-10-06 14:33David ColeFixed in Version => CMake 2.8.3
2010-11-09 22:57Philip LowmanStatusresolved => closed

Notes
(0018964)
David Cole   
2009-12-21 15:27   
The whole concept of fixup_bundle is based on the assumption that you have a bundle containing some set of executable files (*.exes and *.dll/dylib/so) to begin with.

And that you then want to copy in some extra libraries (pluigns).

And then fixup all the binaries inside the bundle so that it's self-contained by pulling in any copies of necessary/required 3rd-party non-system libraries...

I think I let us get off track of that vision by allowing a previous patch that classified "dlls" as non-executables. (Because the corresponding files on Linux/Mac were "not executables") -- but they *all* are executables with respect to fixup_bundle.

I think rather than change this 1 to 0 as recommended by this bug... that we should have two inputs to fixup_bundle: a set of files to copy-in first and a separate set of files to just do the fixups on.

Does this make sense...?
(0018965)
Clinton Stimpson   
2009-12-21 15:38   
I don't think BundleUtilities can know enough about how to deal with plugins. For example, they aren't always in the bin folder or in the Contents/MacOS folder. For Qt plugins, they are actually in Contents/plugins on Mac and bin/plugins on Linux/Windows. But that can be changed from defaults to custom paths by modifying a qt.conf file that gets put into the bundle. So I thought the burden of installing plugins was on the user, not BundleUtilties.

With that understanding, I had always assumed that the first argument to fixup_bundle was a list of executables to copy prerequisites for, and that the second argument was a list of plugins to copy prerequisites for (because they wouldn't get picked up any other way).
(0018967)
Clinton Stimpson   
2009-12-21 15:41   
And one more about the Qt plugins, the path to Qt plugins is actually the root folder containing more sub folders with plugins. So it would never work to have Qt plugins copied into a flat executable/library directory.
(0020215)
Clinton Stimpson   
2010-04-16 10:25   
What's the benefit of a parameter to copy-in files instead of using the install() command? I've been using install() commands because that's the only way I can get the level of control I need.
(0021731)
Mike McQuaid   
2010-08-12 09:15   
In this case, would it not make more sense to try and fix BundleUtilities so it works when installing Qt plugins? It seems quite a few people are using this with Qt so even some special casing might be nice here.
(0021799)
Mike McQuaid   
2010-08-18 04:55   
The fix here seems to be implemented properly in http://public.kitware.com/Bug/view.php?id=10417 [^] and that works for me to fix this problem.
(0022121)
David Cole   
2010-09-07 22:29   
Fixed by the same change that fixed 0010417 :
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e93a4b4d3421ced7b8c852b76c0dcb427f798df8 [^]

Should be in the 2.8.3 release.