View Issue Details Jump to Notes ] Print ]
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}")
TagsNo tags attached.
Attached Files

 Relationships
parent of 0010417closedDavid Cole BundleUtilities/GetPrerequisites not doing bundleutilities example correctly 

  Notes
(0018964)
David Cole (manager)
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 (developer)
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 (developer)
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 (developer)
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 (reporter)
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 (reporter)
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 (manager)
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.

 Issue History
Date Modified Username Field Change
2009-10-20 13:19 Clinton Stimpson New Issue
2009-10-20 13:33 Bill Hoffman Status new => assigned
2009-10-20 13:33 Bill Hoffman Assigned To => David Cole
2009-12-21 15:27 David Cole Note Added: 0018964
2009-12-21 15:38 Clinton Stimpson Note Added: 0018965
2009-12-21 15:41 Clinton Stimpson Note Added: 0018967
2010-04-16 10:25 Clinton Stimpson Note Added: 0020215
2010-08-05 17:28 Clinton Stimpson Relationship added parent of 0010417
2010-08-12 09:15 Mike McQuaid Note Added: 0021731
2010-08-18 04:55 Mike McQuaid Note Added: 0021799
2010-08-31 17:57 David Cole Target Version => CMake 2.8.3
2010-09-07 22:29 David Cole Note Added: 0022121
2010-09-07 22:29 David Cole Status assigned => resolved
2010-09-07 22:29 David Cole Resolution open => fixed
2010-10-06 14:33 David Cole Fixed in Version => CMake 2.8.3
2010-11-09 22:57 Philip Lowman Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team