Wow. Very ambitious. I like it...<br><br>Your patch is not all that ugly... :-) But it does refer to some things that are not actually in the patch.<br><br>How about adding a feature request to the bug tracker for this and attaching a zip file (or .tar.gz) with the patch and all the new files that it refers to.<br>
<br>If you could also add a test project with 2 or 3 components in it that demonstrates how to use the new variables you&#39;ve invented, I could see it becoming part of a future CMake release.....<br><br><br>Thanks for getting the ball rolling.<br>
David Cole<br><br><br><div class="gmail_quote">On Thu, Apr 17, 2008 at 12:53 AM, Doug Gregor &lt;<a href="mailto:doug.gregor@gmail.com">doug.gregor@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello all,<br>
<br>
I have a project that consists of several different libraries, each<br>
with its own headers and generated library targets. I use the<br>
COMPONENT option to the install command to put each library&#39;s<br>
installed files into a library-specific component.<br>
<br>
Now, what I would like to do is have these components translate into<br>
separate installation options within a single NSIS installer created<br>
by CPack. NSIS has options to include a &quot;Components&quot; page in the<br>
installer, which allows users to select/deselect specific components<br>
to install. Is there any way to do this with CPack?<br>
CPACK_INSTALL_CMAKE_PROJECTS doesn&#39;t seem flexible enough.<br>
<br>
In anticipation that the answer to the above is &quot;no&quot;, I hacked up a<br>
quick prototype of this functionality based on the CVS trunk. A patch<br>
is atttached. It&#39;s a little ugly, but it&#39;s working for my test case.<br>
Mostly, I&#39;d like to see if there&#39;s interest in this feature or if<br>
anyone else has already done it.<br>
<br>
The basic idea is that for a given project/component pair (as<br>
specified by CPACK_INSTALL_CMAKE_PROJECTS), one can specify a list of<br>
(sub)components that will actually be installed. Each of these<br>
components can be independently selected (or not) by the user. For<br>
example , the command below says that the Boost project&#39;s ALL<br>
component has (sub)components names &quot;Core&quot;, &quot;Filesystem&quot;, and &quot;Graph&quot;<br>
<br>
 &nbsp;set(CPACK_COMPONENTS_BOOST_ALL &quot;Core&quot; &quot;Filesystem&quot; &quot;Graph&quot;)<br>
<br>
Those names corresponding, of course, to components in an install<br>
command, e.g., the &quot;Core&quot; component installs its files like this:<br>
<br>
install(DIRECTORY boost<br>
 &nbsp; &nbsp; &nbsp; &nbsp;DESTINATION ${BOOST_HEADER_DIR}<br>
 &nbsp; &nbsp; &nbsp; &nbsp;COMPONENT Core<br>
 &nbsp; &nbsp; &nbsp; &nbsp;PATTERN &quot;CVS&quot; EXCLUDE<br>
 &nbsp; &nbsp; &nbsp; &nbsp;REGEX &quot;.svn&quot; EXCLUDE)<br>
<br>
Now the installer has a &quot;Components&quot; page with three entries on it:<br>
<br>
 &nbsp;+ Core<br>
 &nbsp;+ Filesystem<br>
 &nbsp;+ Graph<br>
<br>
Users can choose to install any combination of those by<br>
checking/unchecking the boxes. However, we really don&#39;t want the<br>
installer to say just &quot;Core&quot;, we want it to say &quot;Core Libraries&quot;. In<br>
addition, the &quot;Core Libraries&quot; is a required feature, and must always<br>
be installed. So we add a few more variables before including CPack:<br>
<br>
 &nbsp;set(CPACK_COMPONENT_BOOST_CORE_REQUIRED ON)<br>
 &nbsp;set(CPACK_COMPONENT_BOOST_CORE_DISPLAY_NAME &quot;Core libraries&quot;)<br>
<br>
Now the generated installer shows the Core component as &quot;Core<br>
libraries&quot;, which is checked but grayed out (and not modifiable).<br>
<br>
There are lots of cool features that *could* be added from here, with<br>
some level of NSIS scripting knowledge:<br>
 &nbsp;- Placing components into subgroups (e.g., we could have &quot;headers&quot;,<br>
&quot;runtime libraries&quot;, and &quot;development libraries&quot; under each component)<br>
 &nbsp;- Providing different installation types (runtime, development,<br>
custom) that pre-select sets of components<br>
 &nbsp;- Representing dependencies among components, so that selecting a<br>
component selects all of its dependencies (and unselecting a component<br>
unselects all of the components that depend on it)<br>
 &nbsp;- Provide add/remove support on a per-component basis.<br>
<br>
Comments? Ideas? Rotten tomatoes?<br>
<font color="#888888"><br>
 &nbsp;- Doug<br>
</font><br>_______________________________________________<br>
CMake mailing list<br>
<a href="mailto:CMake@cmake.org">CMake@cmake.org</a><br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br></blockquote></div><br>