View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0011126 | CMake | Modules | public | 2010-08-13 06:35 | 2010-12-13 11:01 | ||||
Reporter | Mike McQuaid | ||||||||
Assigned To | Clinton Stimpson | ||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | no change required | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake-2-8 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0011126: get_prerequisites should return full path (or have option to) | ||||||||
Description | The normal use-case of get_prerequisites I've seen has been to get all the necessary 3rd-party libraries and install them with the application. I think this could be made much easier by providing an option (or variable a user can set) that allows get_prerequisites to return the list of resolved items rather than unresolved ones. They have already been resolved so it would be great if you could just install the variable of returned values rather than having to loop through them, resolve each one and install it manually. I can write a patch which will provide this feature, if requested and approved. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0021739) Mike McQuaid (reporter) 2010-08-13 06:49 |
Thinking about this further, ideally there'd be a install_prerequisites function you could call (with the same parameters as get_prerequisites) which would use install(code ...) to add all the necessary code to install the prerequisites for an executable from your CMake code (rather than from cmake_install files) to have a single function that allows you to get all the prerequisites, resolve them and install them correctly. It would be good, also, if calling this on a .app bundle would use the fixup_bundle function to perform the same action, meaning less platform-specific branching would be needed. Again, if this is OK'd or should be in another bug, let me know and I'll move it and/or write a patch to implement this. |
(0021815) Clinton Stimpson (developer) 2010-08-18 19:30 |
How does this compare to BundleUtilities? Or, what are you trying to do that BundleUtilties can't do for you? And how would one know what prerequisites for an executable to put in a cmake file if the executable hasn't been compiled yet? |
(0021821) Mike McQuaid (reporter) 2010-08-19 03:47 |
BundleUtilities only works on OSX, right? It won't build me a flattened directory structure to install on Windows or Linux. What I'm trying to do is minimise the amount of code you have to write on OSX for BundleUtilities and provide the seem, concise syntax on Windows and Linux. For example: IF ( APPLE ) INSTALL( CODE " IF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* ) FILE( INSTALL DESTINATION \"\${CMAKE_INSTALL_PREFIX}/Charm.app/Contents/plugins/sqldrivers\" TYPE FILES \${QT_SQL_PLUGINS} ) FILE( GLOB QT_SQL_PLUGINS \"\${CMAKE_INSTALL_PREFIX}/Charm.app/Contents/plugins/sqldrivers/*\" ) INCLUDE( GetPrerequisites ) INCLUDE( \"${CMAKE_SOURCE_DIR}/CMake/Modules/BundleUtilities.cmake\" ) SET( chmod_bundle_items TRUE ) FIXUP_BUNDLE( \"\${CMAKE_INSTALL_PREFIX}/Charm.app\" \"\${QT_SQL_PLUGINS}\" \"\" ) ENDIF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* ) " ) ENDIF ( APPLE ) This is what I currently have to do to fixup my Bundle on OSX. Here you can see a few references to other bugs, the package-time-only installation (http://public.kitware.com/Bug/view.php?id=11142 [^]), the Qt plugins (http://public.kitware.com/Bug/view.php?id=11145 [^]) and making libraries writable for BundleUtilities (http://public.kitware.com/Bug/view.php?id=9284 [^]). What I'm aiming for is to be able to just specify the executable (and any plugins) and have all the above done automatically on all platforms, just not OSX. As you point out, you can't know the prerequisites for an uncompiled executable but you can work out these prerequisites at install or package time using the code I showed above. However, particularly for people new to CMake/CPack, the syntax is pretty horrible and unnecessarily verbose. What I would propose would be something like: install_prerequisites(EXECUTABLE DESTINATION EXCLUDE_SYSTEM RECURSE SEARCHDIRS EXEPATH PLUGINS MAKEPACKAGEONLY) and possibly, if you couldn't work out how to do that automatically for bundles (which I think I could do): install_bundle(BUNDLE LIBRARIES PLUGINS SEARCHDIRS MAKEPACKAGEONLY) The variables would be basically the same as in CMake except plugins could be installed differently and MAKEPACKAGEONLY could specify if the installation should occur only at packaging time. |
(0021826) Mike McQuaid (reporter) 2010-08-19 04:45 |
Having a look at the source/output of macdeployqt, it looks like it just installs all the relevant plugins for a module when it installs the plugin. Considering all the plugins are, uncompressed, 3MB on OSX, this probably isn't a bad idea. http://public.kitware.com/Bug/view.php?id=11145 [^] is probably relevant to the discussion here. |
(0021838) Clinton Stimpson (developer) 2010-08-19 09:34 |
BundleUtilities was ported to Windows and Linux. See: http://www.cmake.org/Wiki/BundleUtilitiesExample [^] |
(0021840) Mike McQuaid (reporter) 2010-08-19 09:40 |
Ok, maybe I'm being stupid here, but I don't want a directory with Contents/ and Frameworks/ inside them on Windows and Linux? |
(0021841) Mike McQuaid (reporter) 2010-08-19 09:56 |
Ok, I've tried this out. The BundleUtilities port to Windows and Linux, I'd argue, makes very little sense at all. How is a user meant to have any idea that "fixup_bundle" or indeed "BundleUtilities" actually makes a deployable target? I'd assumed until now, because of the naming and documentation, that the port to Linux/Windows meant you could make a .app style bundle with Contents/ and Frameworks/ etc. on Linux/Windows. In this case, BundleUtilities seems to work (other than, for example, the bugs I mentioned before). I still think it would be good to have the suggested install_bundle and MAKEPACKAGEONLY features to mean that the user doesn't have to fight with the fairly nasty syntax and escaping issues involve in INSTALL(CODE). |
(0021844) Clinton Stimpson (developer) 2010-08-19 10:20 |
Yes, the naming was discussed when it was ported. "Bundle" wasn't a Windows/Linux term, but kitware decided to keep using that term. I wonder if you'll find it easier to use INSTALL(SCRIPT ...) instead of INSTALL(CODE ...) then you don't have to worry about escaping quotes and dollar signs. |
(0021845) Mike McQuaid (reporter) 2010-08-19 10:25 |
Install(SCRIPT) is easier but it's still hard to get variables in and out. I'm not sure you couldn't just provide an install_bundle target which would simplify this for the user? Also, with the naming, perhaps it's possible to create a dummy script called InstallPrerequisites or something which then calls BundleUtilities. At least this would be more discoverable. |
(0021846) Clinton Stimpson (developer) 2010-08-19 10:47 |
Anyway, I think you are up to speed on the work that has been put into this already, and some of what you are asking has already been done. I just wanted to make sure you were aware of the work already done. So, this particular bug didn't seem valid since BundleUtilities does this work and already works on multiple platforms. For any further improvements, I suggest you get buy-in from Kitware. |
(0021847) Mike McQuaid (reporter) 2010-08-19 11:04 |
Ok, do you want me to create another bug to request the commend to create the install(code) stuff and the package-time-only generation? I'm not sure what you mean by buy-in from Kitware, are you not part of Kitware? Who would I speak to about this? |
(0021849) Clinton Stimpson (developer) 2010-08-19 15:45 |
Its not just Kitware that has access to this bug system. If you have proposals, you could go to the mailing list first, and let people discuss. I think you'll get better results starting there, and a path forward can be decided there. |
(0023917) Mike McQuaid (reporter) 2010-12-13 07:11 |
This can probably be closed, any additional functionality desired has been encompassed by other bugs I've filed. Thanks! |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2010-08-13 06:35 | Mike McQuaid | New Issue | |
2010-08-13 06:49 | Mike McQuaid | Note Added: 0021739 | |
2010-08-18 19:30 | Clinton Stimpson | Note Added: 0021815 | |
2010-08-19 03:47 | Mike McQuaid | Note Added: 0021821 | |
2010-08-19 04:45 | Mike McQuaid | Note Added: 0021826 | |
2010-08-19 09:34 | Clinton Stimpson | Note Added: 0021838 | |
2010-08-19 09:40 | Mike McQuaid | Note Added: 0021840 | |
2010-08-19 09:56 | Mike McQuaid | Note Added: 0021841 | |
2010-08-19 10:20 | Clinton Stimpson | Note Added: 0021844 | |
2010-08-19 10:25 | Mike McQuaid | Note Added: 0021845 | |
2010-08-19 10:47 | Clinton Stimpson | Note Added: 0021846 | |
2010-08-19 11:04 | Mike McQuaid | Note Added: 0021847 | |
2010-08-19 15:45 | Clinton Stimpson | Note Added: 0021849 | |
2010-12-13 07:11 | Mike McQuaid | Note Added: 0023917 | |
2010-12-13 11:01 | Clinton Stimpson | Status | new => closed |
2010-12-13 11:01 | Clinton Stimpson | Assigned To | => Clinton Stimpson |
2010-12-13 11:01 | Clinton Stimpson | Resolution | open => no change required |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |