View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0009744 | CMake | Modules | public | 2009-10-20 13:19 | 2010-11-09 22:57 | ||||
Reporter | Clinton Stimpson | ||||||||
Assigned To | David Cole | ||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | CMake 2.8.3 | Fixed in Version | CMake 2.8.3 | ||||||
Summary | 0009744: BundleUtilities making extra copies of plugins | ||||||||
Description | Extra 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}") | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | ||||||
|
Relationships |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |