On Fri, Aug 20, 2010 at 7:37 AM, Mike McQuaid <span dir="ltr"><<a href="mailto:mike@mikemcquaid.com">mike@mikemcquaid.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
There's been some discussion on <a href="http://public.kitware.com/Bug/view.php?id=11126" target="_blank">http://public.kitware.com/Bug/view.php?id=11126</a> and I raised the issue about the BundleUtilities port to Windows/Linux: the naming is so bad as to make this (pretty cool) feature completely undiscoverable. </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I assumed, as I'd think others would, that this would be somehow related to creating .app bundle clones on Linux or Windows, not fixing up the dependencies and installing them. I'd argue that anything relating to the latter really belongs in GetPrerequisites and should be named differently.<br>
<br>
For backwards compatibility purposes, obviously the current naming will still need to work but is it possible to get some of this functionality documented and described in a better location?<br></blockquote><div><br></div>
<div>Sorry about that. The name was chosen when the functionality was Mac-only, then we extended it to cover Windows/Linux. What name would you suggest as "more discoverable" or "better"?</div><div><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Secondly, I'd like to propose a function like "install_prerequisites" which would create all the INSTALL(CODE) stuff for you and call the various needed functions, just to make it easier for people to be able to use bundleutilities/getprerequisites without having to fight with INSTALL(CODE or SCRIPT) problems.<br>
</blockquote><div><br></div><div>Well, since it needs all the files to exist at analysis time, such a command would have to generate code that is run at install time. I'd be surprised if you could easily generalize this such that a client project would not have to customize it at all, but I could be wrong...</div>
<div><br></div><div>I'm not a big fan of making all this stuff "too automatic" (which is a completely subjective judgment call, but still...) -- because I think it's a good thing that developers have to be aware of all the dependencies in their code. If we make this completely automatic, people will blame CMake when they inadvertently pull in some GPL-ed component that they don't really *want* to depend on. Pushing the work onto the end-developer has the nice side effect of placing the responsibility for such inclusions directly on the end-developer. (Which is where it belongs.)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Thirdly, I often want to install prerequisites or other files into the packages generated by CPack but not when using make install. It would be good if INSTALL(CODE) or other functions could have an argument to do basically this:<br>
IF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )<br>
<<<Stuff passed to INSTALL(CODE) in here>>><br>
ENDIF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )<br></blockquote><div><br></div><div>Not a big fan of this one either. Personally, I think it's stupid even to have differences between the build tree and the install tree. Now, with this, you'd have differences between the "make install" tree and the packaged install tree...? Why do you do this? Just to save devs some time at "make install" time? Or is there some other valid technical reason that my foggy morning brain isn't thinking of...?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I'm happy to help or develop these features, if they'd be accepted. It was suggested that both would require Kitware buy-in before I should start working on them.<br></blockquote><div><br></div><div>Thanks for opening these discussions, by the way. Good to know people are using this stuff even though they have to work through stuff to get to the end result.</div>
<div><br></div><div><br></div><div>HTH,</div><div>David</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Thanks!<br>
--<br>
Cheers,<br>
Mike McQuaid<br>
<a href="http://mikemcquaid.com" target="_blank">http://mikemcquaid.com</a><br>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div><br>