On Sat, Apr 17, 2010 at 1:02 AM, Clinton Stimpson <span dir="ltr"><<a href="mailto:clinton@elemtech.com">clinton@elemtech.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;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Apr 16, 2010, at 9:13 AM, David Cole wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Fri, Apr 16, 2010 at 11:03 AM, Michael Wild <span dir="ltr"><<a href="mailto:themiwi@gmail.com" target="_blank">themiwi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
The way BundleUtilities (that is, GetPrerequisites is actually doing the work here) is designed so far is to check for run-time dependencies using otool and similar utilities. However, CMake can't possibly detect that qt_menu.nib is required since this file is loaded dynamically at run-time, so someone has to put that information into GetPrerequisites. Since qt_menu.nib is a rather recent addition to Qt, and most people use their own scripts to accomplish this, it hasn't happened so far. Also, there's the issue of whether one actually wants to hard-code such specific information into a general tool like GetPrerequisites... The danger of creating a huge number of unmaintainable special cases is quite big there...<br>
<br>
Perhaps one could devise a way for FindXXX/XXConfig modules to communicate such requirements to GetPrerequisites using properties. This approach would be much more modular and wouldn't require GetPrerequisites to be updated every time a module changes.<br>
<font color="#888888"></font><br></blockquote></div><br>As the primary author of GetPrerequisites and BundleUtilities, I'm gonna chime in here, even though I don't have time in the near term future to do much useful work on the topic...<br>
<br>I think that the missing *.nib files should be accounted for by adding the capability to BundleUtilities to copy *all* of the files in a copied framework. Right now, it copies *only* the actual binary dylib files to minimize the size of the resulting bundle. Clearly that does not work for libraries that depend on embedded resources that are in other parts of the framework. I would like, moving forward, to add the ability to say "copy everything" or "copy this list of extra stuff" for any given framework that gets pulled in because it is a prereq.<br>
</blockquote><div><br></div></div><div>I'm looking at the simple example of a framework given here (Listing 1):</div><div><<a href="http://devworld.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html" target="_blank">http://devworld.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html</a>></div>
<div>What if we just add the Resources directory if it exist for the version of the framework being used? In other words, if Resources exists, assume its needed to make the framework functional. I've attached a patch that does this.</div>
<div></div></div></div><br><div style="word-wrap:break-word"><div><div></div><div>This would fix the Qt/Cocoa problem.</div><div><br></div><div>Then what if it was a further extension to optionally include more parts of the framework or the entire framework, like you are suggesting?</div>
<div><br></div><div>Clint</div><div><br></div></div></div><br></blockquote></div><br><div>Excellent idea. I will work with this patch next week some time and see if I can't get it applied.</div><div><br></div><div>Thx,</div>
<div>David</div><div><br></div>