Hi Sascha,
thanks for the tips. I believe I now have 3 apps working with a selection of
different plugins for each app. The suggestions you provided were very useful
thanks.
However, I did hit 2 issues, the second of which I think needs an MITK change:
1. For external projects, setting MACOSX_BUNDLE_NAMES to contain multiple apps
results in invalid bundles.
I have 3 apps. I set MACOSX_BUNDLE_NAMES to contain those 3 names. The 3 apps
compile. When I do "make install", and presumably the same for "make package",
the MITK_INSTALL command causes my libraries to be copied into each bundle....
which is fine. But the call to FunctionCreateBlueBerryApplication causes all
the MITK and CTK plugins to be copied into each bundle, for each time the
FunctionCreateBlueBerryApplication is called.
With MACOSX_BUNDLE_NAMES=NiftyView;NiftyMIDAS;NiftyIGI
you get the following sequence (some parts omitted for brevity):
a) Calling mitkInstallRules causes stuff like this, as expected:
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyView.app/Contents/MacOS/StateMachine.xml
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyMIDAS.app/Contents/MacOS/StateMachine.xml
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyIGI.app/Contents/MacOS/StateMachine.xml
b)My project libraries get copied. In this case, I may prefer to not copy all
libraries to all bundles, but even if they are all physically copied, as long
as the provisioning file is correct I don't mind:
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyView.app/Contents/MacOS/plugins/libuk_ac_ucl_cmic_gui_qt_commonapps.dylib
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyMIDAS.app/Contents/MacOS/plugins/libuk_ac_ucl_cmic_gui_qt_commonapps.dylib
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyIGI.app/Contents/MacOS/plugins/libuk_ac_ucl_cmic_gui_qt_commonapps.dylib
c) MITK and CTK libraries are copied in HOWEVER, even though I am currently
only processing NiftyView, they get copied to all 3 bundles. (I did just check,
the plugins that have been excluded when calling
FunctionCreateBlueBerryApplication are not copied over, which is good.)
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyView.app/Contents/MacOS/plugins/liborg_commontk_configadmin.dylib
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyView.app/Contents/MacOS/plugins/liborg_commontk_eventadmin.dylib
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyView.app/Contents/MacOS/plugins/liborg_blueberry_osgi.dylib
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyView.app/Contents/MacOS/plugins/liborg_blueberry_compat.dylib
<snip>
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyMIDAS.app/Contents/MacOS/plugins/liborg_commontk_configadmin.dylib
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyMIDAS.app/Contents/MacOS/plugins/liborg_commontk_eventadmin.dylib
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyMIDAS.app/Contents/MacOS/plugins/liborg_blueberry_osgi.dylib
<snip>
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyIGI.app/Contents/MacOS/plugins/liborg_commontk_configadmin.dylib
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyIGI.app/Contents/MacOS/plugins/liborg_commontk_eventadmin.dylib
-- Installing:
/Users/mattclarkson/install/niftk-debug/NiftyIGI.app/Contents/MacOS/plugins/liborg_blueberry_osgi.dylib
this I could live with if it only happened once.
d) NiftyView is then fixed up, using fixup_bundle, where the list of libraries
is all MITK, CTK, Qt and CTK Designer plugins (see bug: 13504 which I have
merged in my version of MITK)
e) NiftyView is then validated OK.
f) The second app is then processed. However, we again see that all MITK and
CTK libraries are copied to EACH BUNDLE. This means that all the values of
@executable_path that were set for NiftyView are now un-set (wrong). And the
value of @executable_path is not fixed again, as processing has now moved onto
the second application.
g) This continues, the end result being that only the last application is a
valid bundle, all previous apps have been broken by the last app overwriting
all the MITK and CTK bundles.
I managed to work around this be doing (pseudo code)
SET(TMP_MACOSX_BUNDLE_NAMES ${MACOSX_BUNDLE_NAMES})
SET(MACOSX_BUNDLE_NAMES ${MY_APP_NAME})
FunctionCreateBlueBerryApplication(
NAME ${MY_APP_NAME}
<snip>
SET(MACOSX_BUNDLE_NAMES ${TMP_MACOSX_BUNDLE_NAMES})
so, by only having MACOSX_BUNDLE_NAMES contain one application name at the
point the application is created stopped the incorrect copying of libraries.
2. The second item I believe to be wrong. If I create an application, and I
specifically exclude a plugin, such as liborg_mitk_gui_qt_stdmultiwidgeteditor,
then for MITK plugins that are excluded, they are not installed within the
bundle. This is as expected. However, when doing the fixup_bundle we see:
override:
/Users/mattclarkson/build/NifTK-SuperBuild/MITK-build/MITK-build/bin/plugins/liborg_mitk_gui_qt_stdmultiwidgeteditor.dylib
found file: /liborg_mitk_gui_qt_stdmultiwidgeteditor.dylib
override result:
So, this plugin is resolved to /liborg_mitk_gui_qt_stdmultiwidgeteditor.dylib
This causes it to subsequently be copied to / which would fail on any machine
where write permission was not set, but then the file is kept within the list
of available files to check, and further on you get:
-- 438/484: fixing up '/liborg_mitk_gui_qt_stdmultiwidgeteditor.dylib'
CMake Error at
/Users/mattclarkson/build/NifTK-SuperBuild/CMakeExternals/Source/MITK/CMake/BundleUtilities.cmake:549
(string):
string end index: 55 is out of range -1 - 46
Call Stack (most recent call first):
/Users/mattclarkson/build/NifTK-SuperBuild/CMakeExternals/Source/MITK/CMake/BundleUtilities.cmake:645
(fixup_bundle_item)
Code/Gui/MITK/Apps/NiftyMIDAS/cmake_install.cmake:426 (fixup_bundle)
Code/Gui/MITK/Apps/cmake_install.cmake:33 (INCLUDE)
Code/Gui/MITK/cmake_install.cmake:54 (INCLUDE)
Code/Gui/cmake_install.cmake:32 (INCLUDE)
Code/cmake_install.cmake:33 (INCLUDE)
cmake_install.cmake:1282 (INCLUDE)
However, something that is not even in the bundle should not even be processed
at this point (BundleUtilities.cmake:549). So, I removed the line:
https://github.com/MITK/MITK/blob/master/CMake/mitkMacroInstall.cmake#L57
and the installation works.
It works because in mitkMacroInstall lines 45-54, we are checking if a plugin
is not contained within the bundle and trying to fix this by searching within
the bundle, and substitute that value for the path. This produces sets
${item_path} to be empty so you see the "found file ${item_path}/${item_name}"
then contains /liborg_mitk_gui_qt_stdmultiwidgeteditor.dylib and this should be
rejected at the next if statement.
What do you think?
Matt
On 25 Sep 2012, at 13:11, Sascha Zelzer wrote:
Hi,
Caspar answered some of the questions already. I will add some more comments.
On 09/24/2012 09:13 PM, Clarkson, Matt wrote:
Hi there,
I hope I haven't asked this before ... :-)
Our project structure closely resembles the MITK-Project Template
https://github.com/MITK/MITK-ProjectTemplate
If I wanted to have several apps, where each app has a different selection of
plugins ... is this possible?
Yes, this is officially supported and is supposed to "just" work if you are
relying on the MITK CMake macros.
I guess it basically means that I need to generate a .provisioning file for
each app, with a different load of plugins in each file.
Yes, but you actually rarely need to create a .provisioning file yourself. The
CMake function
FunctionCreateBlueBerryApplication
http://docs.mitk.org/nightly-qt4/BlueBerry/reference/api/html/namespaceCMake.html#a9f16f167e718f5d68edf4c12f6ed320c
or specifically
FunctionCreateProvisioningFile (normally called from
FunctionCreateBlueBerryApplication)
http://docs.mitk.org/nightly-qt4/BlueBerry/reference/api/html/namespaceCMake.html#a9f16f167e718f5d68edf4c12f6ed320c
does that for you. If you explicitly define a set of plugins to be included,
you only need to list plugins which are not required by other plug-ins already
listed. Plugin dependencies will be automatically enable in the build system
and added to the provisioning file.
The reason I ask, is that it might be a bit fiddly with things like Mac
application structure???
Yes, but we invested quite some time to hide that fact from the users of our
CMake install macros.
If a plug-in is used by two or more applications, it is shared between them on
Linux and Windows but gets duplicated during the install process on a Mac.
In MITK, we currently have three applications: CoreApp, mitkDiffusion and
mitkWorkbench
https://github.com/MITK/MITK/tree/master/Applications
See also
https://github.com/MITK/MITK/blob/master/Applications/AppList.cmake
and especially the CMake code starting here
https://github.com/MITK/MITK/blob/master/CMakeLists.txt#L369
the variable MACOSX_BUNDLE_NAMES is important because its contents is read in by
https://github.com/MITK/MITK/blob/master/CMake/mitkInstallRules.cmake
which is meant to be included by external projects to get the install stuff
right. MITK includes that file itself here:
https://github.com/MITK/MITK/blob/master/CMakeLists.txt#L833
- Sascha
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
