What Clinton wants, though, is the ability to just put his make install tree into the .dmg, not put it inside another bundle. His make install tree contains a bundle already.<div><br><br><div class="gmail_quote">On Fri, Jan 16, 2009 at 11:38 AM, Timothy M. Shead <span dir="ltr"><<a href="mailto:tshead@sandia.gov">tshead@sandia.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">David Cole wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tim,<br>
<br>
Thanks for chiming in.<br>
<br>
Did my suggestion about possibly just modifying the bundle generator to also enable using the "make install" tree as is make sense to you, or does it seem like that should be a separate CPack generator?<br>
</blockquote>
<br></div>
I'm not sure if there is some difference in our use of terminology, but this is exactly how I would describe the current behavior - the bundle generator generates a dmg containing a single bundle (just as the NSIS generator generates a single NSIS executable) that contains the install tree defined by your CMake INSTALL() commands.<div>
<div></div><div class="Wj3C7c"><br>
<br>
Cheers,<br>
Tim<br>
<br>
-- <br>
Timothy M. Shead<br>
Data Analysis & Visualization (1424)<br>
Sandia National Laboratories<br>
505-284-0139<br>
<br>
</div></div></blockquote></div><br></div>