Doug Gregor
2008-04-17 04:53:01 UTC
Hello all,
I have a project that consists of several different libraries, each
with its own headers and generated library targets. I use the
COMPONENT option to the install command to put each library's
installed files into a library-specific component.
Now, what I would like to do is have these components translate into
separate installation options within a single NSIS installer created
by CPack. NSIS has options to include a "Components" page in the
installer, which allows users to select/deselect specific components
to install. Is there any way to do this with CPack?
CPACK_INSTALL_CMAKE_PROJECTS doesn't seem flexible enough.
In anticipation that the answer to the above is "no", I hacked up a
quick prototype of this functionality based on the CVS trunk. A patch
is atttached. It's a little ugly, but it's working for my test case.
Mostly, I'd like to see if there's interest in this feature or if
anyone else has already done it.
The basic idea is that for a given project/component pair (as
specified by CPACK_INSTALL_CMAKE_PROJECTS), one can specify a list of
(sub)components that will actually be installed. Each of these
components can be independently selected (or not) by the user. For
example , the command below says that the Boost project's ALL
component has (sub)components names "Core", "Filesystem", and "Graph"
set(CPACK_COMPONENTS_BOOST_ALL "Core" "Filesystem" "Graph")
Those names corresponding, of course, to components in an install
command, e.g., the "Core" component installs its files like this:
install(DIRECTORY boost
DESTINATION ${BOOST_HEADER_DIR}
COMPONENT Core
PATTERN "CVS" EXCLUDE
REGEX ".svn" EXCLUDE)
Now the installer has a "Components" page with three entries on it:
+ Core
+ Filesystem
+ Graph
Users can choose to install any combination of those by
checking/unchecking the boxes. However, we really don't want the
installer to say just "Core", we want it to say "Core Libraries". In
addition, the "Core Libraries" is a required feature, and must always
be installed. So we add a few more variables before including CPack:
set(CPACK_COMPONENT_BOOST_CORE_REQUIRED ON)
set(CPACK_COMPONENT_BOOST_CORE_DISPLAY_NAME "Core libraries")
Now the generated installer shows the Core component as "Core
libraries", which is checked but grayed out (and not modifiable).
There are lots of cool features that *could* be added from here, with
some level of NSIS scripting knowledge:
- Placing components into subgroups (e.g., we could have "headers",
"runtime libraries", and "development libraries" under each component)
- Providing different installation types (runtime, development,
custom) that pre-select sets of components
- Representing dependencies among components, so that selecting a
component selects all of its dependencies (and unselecting a component
unselects all of the components that depend on it)
- Provide add/remove support on a per-component basis.
Comments? Ideas? Rotten tomatoes?
- Doug
I have a project that consists of several different libraries, each
with its own headers and generated library targets. I use the
COMPONENT option to the install command to put each library's
installed files into a library-specific component.
Now, what I would like to do is have these components translate into
separate installation options within a single NSIS installer created
by CPack. NSIS has options to include a "Components" page in the
installer, which allows users to select/deselect specific components
to install. Is there any way to do this with CPack?
CPACK_INSTALL_CMAKE_PROJECTS doesn't seem flexible enough.
In anticipation that the answer to the above is "no", I hacked up a
quick prototype of this functionality based on the CVS trunk. A patch
is atttached. It's a little ugly, but it's working for my test case.
Mostly, I'd like to see if there's interest in this feature or if
anyone else has already done it.
The basic idea is that for a given project/component pair (as
specified by CPACK_INSTALL_CMAKE_PROJECTS), one can specify a list of
(sub)components that will actually be installed. Each of these
components can be independently selected (or not) by the user. For
example , the command below says that the Boost project's ALL
component has (sub)components names "Core", "Filesystem", and "Graph"
set(CPACK_COMPONENTS_BOOST_ALL "Core" "Filesystem" "Graph")
Those names corresponding, of course, to components in an install
command, e.g., the "Core" component installs its files like this:
install(DIRECTORY boost
DESTINATION ${BOOST_HEADER_DIR}
COMPONENT Core
PATTERN "CVS" EXCLUDE
REGEX ".svn" EXCLUDE)
Now the installer has a "Components" page with three entries on it:
+ Core
+ Filesystem
+ Graph
Users can choose to install any combination of those by
checking/unchecking the boxes. However, we really don't want the
installer to say just "Core", we want it to say "Core Libraries". In
addition, the "Core Libraries" is a required feature, and must always
be installed. So we add a few more variables before including CPack:
set(CPACK_COMPONENT_BOOST_CORE_REQUIRED ON)
set(CPACK_COMPONENT_BOOST_CORE_DISPLAY_NAME "Core libraries")
Now the generated installer shows the Core component as "Core
libraries", which is checked but grayed out (and not modifiable).
There are lots of cool features that *could* be added from here, with
some level of NSIS scripting knowledge:
- Placing components into subgroups (e.g., we could have "headers",
"runtime libraries", and "development libraries" under each component)
- Providing different installation types (runtime, development,
custom) that pre-select sets of components
- Representing dependencies among components, so that selecting a
component selects all of its dependencies (and unselecting a component
unselects all of the components that depend on it)
- Provide add/remove support on a per-component basis.
Comments? Ideas? Rotten tomatoes?
- Doug