<div class="gmail_quote">On Mon, Jul 20, 2009 at 2:12 PM, Clinton Stimpson <span dir="ltr">&lt;<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Would the general cmake solution for find_program/find_library do something like this:<br>
dumpbin /headers {some.lib|some.dll|some.exe} | findstr &quot;machine&quot;  ?<br>
I get either AMD64 or x86 in the output from that.</blockquote><div><br></div><div>Yes. Or something that&#39;s equivalent... More likely something that&#39;s equivalent because I don&#39;t think a hard dependency on dumpbin to provide core cmake functionality is such a good idea.</div>

<div><br></div><div>But... it also has to know which one you want. That&#39;s the more difficult part of the problem. Either we have to add args to the signature of find_program that says &quot;only give me 64-bit results&quot; (or 32-bit) or we have to have a way to infer what a caller of find_program is looking for. Adding args everywhere is probably the only &quot;real&quot; solution -- inferring things is always a bit dicey.</div>
<div><br></div><div>It&#39;s also more general than Win32 / Win64 -- if you are doing &quot;FIND_LIBRARY&quot; stuff, you want the libraries found to match the architecture of the thing you&#39;re building. Same thing applies to 32/64 on Linux and Mac and even ppc/intel on Mac ... and cross compiling and ...    It&#39;s just a can of worms we have not opened yet.</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
If find_program did it right, then gp_resolve_item would give me the right .dll file.<br>
<br>
Clint<br>
<br>
David Cole wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>
On Mon, Jul 20, 2009 at 1:39 PM, Clinton Stimpson &lt;<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>&gt;&gt; wrote:<br>


<br>
<br>
    Thanks.  Do you know if gp_resolve_item handles 64 and 32 bit<br>
    binaries correctly on Windows?<br>
<br>
<br>
Definitely not. On Windows, it uses find_program to find the dlls in the PATH or in a list of directories provided by the caller... This is only based on dll name, so it could potentially return improper results (with respect to 32- and 64-bit dlls). You can either: fix gp_resolve_item to consider the bit-ness of the result, or provide a cmake function named &quot;gp_resolve_item_override&quot; in which you deliver the result in your own code. Preferably, add code to gp_resolve_item to match the bit-ness of the result with the bit-ness of the input...<br>


<br>
(Personally, I would really like to see a general CMake solution to the problem of matching library bit-ness for Win32 and Win64 uses of find_library / find_program.... That may be a bit beyond the scope of what you&#39;re hoping to achieve here though.)<br>


<br>
Keep up the good work! Sounds like you are making progress on this stuff... :-)<br>
<br>
<br>
David<br>
<br>
<br>
 <br>
<br>
    &quot;dumpbin /dependents&quot; is used and it doesn&#39;t return full paths<br>
    like ldd does on Linux, or otool on Mac.<br>
    I put both in my PATH, so I can run both 32 and 64 bit programs.<br>
     I just wanted to make sure I was getting the right .dll when I<br>
    copy it into my installation directory.<br>
<br>
    Clint<br>
<br>
    David Cole wrote:<br>
<br>
        On Fri, Jul 17, 2009 at 6:48 PM, David Cole<br>
        &lt;<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a> &lt;mailto:<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a>&gt;<br>
        &lt;mailto:<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a><br>
        &lt;mailto:<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a>&gt;&gt;&gt; wrote:<br>
<br>
           No. It&#39;s supposed to return the actual string that is<br>
        referenced<br>
           by the thing being analyzed. But you can call<br>
        gp_resolve_item to<br>
           get the full path... (There is a reason for this, although<br>
        I can&#39;t<br>
           remember what it is at the moment... If I think of it, I&#39;ll<br>
        reply<br>
           again.)<br>
<br>
<br>
        I thought of/remembered the reason, so I&#39;m replying again:<br>
<br>
        The get_prerequisites function needs to return items exactly<br>
        as they are referenced in the executable being analyzed such<br>
        that ...... later on, the caller can use that string as an<br>
        input to install_name_tool for replacing it with something<br>
        like &quot;@executable_path/....&quot; -- if the item were returned<br>
        resolved, then we would have to re-analyze the executable<br>
        later to figure out which string in the otool output<br>
        corresponds to the resolved item... (Or keep a map of them<br>
        around, as is done in BundleUtilities...)<br>
<br>
<br>
         <br>
           From commentary in the middle of the get_prerequisites<br>
        function:<br>
<br>
               # Use the raw_item as the list entries returned by this<br>
           function. Use the<br>
               # gp_resolve_item function to resolve it to an actual full<br>
           path file if<br>
               # necessary.<br>
               #<br>
               set(item &quot;${raw_item}&quot;)<br>
<br>
<br>
           HTH,<br>
           David<br>
<br>
<br>
           On Fri, Jul 17, 2009 at 6:40 PM, Clinton Stimpson<br>
           &lt;<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>&gt;<br></div></div><div><div></div><div>


        &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>&gt;&gt;&gt;<br>
        wrote:<br>
<br>
<br>
               Is get_prerequisites() supposed to return absolute<br>
        paths all<br>
               the time?<br>
               For example, on the Mac, I&#39;ve got some frameworks in<br>
               /Library/Frameworks that I may want to copy if they<br>
        might not<br>
               exist on other Macs.  When I call get_prerequisites(),<br>
        getting<br>
               &quot;foo.framwork/&quot; instead of<br>
        &quot;/Library/Frameworks/foo.framework/&quot;<br>
<br>
               Clint<br>
<br>
               David Cole wrote:<br>
<br>
                   So I would love to see a corollary to<br>
                   BundleUtilities.cmake for Mac on Windows and Linux,<br>
        too.<br>
<br>
                   Using GetPrerequisites to gather the set of dependent<br>
                   files is obviously the first step.<br>
<br>
                   Then, on Windows, a function that installs all the<br>
                   dependent dlls to the same location as the executable<br>
                   would be awesome.<br>
<br>
                   On Linux, I guess you would have to make sure<br>
        everything<br>
                   you depend on is either already installed in its<br>
        install<br>
                   path, or aware of your install path, or uses<br>
                   LD_LIBRARY_PATH -- the issues here are the ones I<br>
        am least<br>
                   familiar with (compared to Windows and Mac anyhow).<br>
<br>
                   I don&#39;t think this should ever be fully automated<br>
        because<br>
                   of licensing and coyright issues. Technically, it<br>
        is easy<br>
                   to gather the set of required files to make<br>
        something work<br>
                   on a practical level. The issue will be: &quot;hey,<br>
        you&#39;re not<br>
                   allowed to copy *that* dll&quot; because of such and such<br>
                   non-technical reason...<br>
<br>
                   Having said all this, and that I would love to see<br>
        it, I<br>
                   must admit: it is not presently on the radar for<br>
        any CMake<br>
                   developers as far as I know. So, as always: patches<br>
                   welcome. :-)<br>
<br>
<br>
                   HTH,<br>
                   David<br>
<br>
<br>
                   On Fri, Jul 17, 2009 at 3:05 PM, Clinton Stimpson<br>
                   &lt;<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>&gt;<br>
        &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>&gt;&gt;<br>
                   &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a><br>
        &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>&gt;<br>
<br>
                   &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a><br>
        &lt;mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>&gt;&gt;&gt;&gt; wrote:<br>
<br>
                      So I&#39;m using GetPrequisites.cmake to gather<br>
        dependencies.<br>
                      Are there any examples, tips, etc.. for using this?<br>
<br>
                      With the results I&#39;m getting back, I do a<br>
                      file(INSTALL ... ) because that&#39;s what I see in the<br>
                      cmake_installcmake file.  Should it be documented?<br>
                      But these files I&#39;m getting back are soft links<br>
        to the real<br>
                      library.  And the file(INSTALL ... ) just puts a<br>
                   softlink in my<br>
                      installation directory instead of a real library.<br>
<br>
                      Is there some higher level cmake function I<br>
        should be<br>
                   calling to<br>
                      install libraries on Unix/Linux, similar to how<br>
        there is<br>
                      BundleUtilties.cmake for Mac?  Or ideally, is<br>
        there one<br>
                   function I<br>
                      can use on all platforms to install some<br>
        prerequisites?<br>
<br>
                      Thanks,<br>
                      Clint<br>
<br>
                      _______________________________________________<br>
                      Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
        &lt;<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>&gt; &lt;<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>&gt;<br>
                   &lt;<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>&gt;<br>
<br>
<br>
                      Visit other Kitware open-source projects at<br>
                      <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<br>
        CMake FAQ at:<br>
                      <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>
<br>
<br>
<br>
               _______________________________________________<br>
               Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a> &lt;<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>&gt;<br>
        &lt;<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>&gt;<br>
<br>
               Visit other Kitware open-source projects at<br>
               <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:<br>
               <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>
<br>
<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br>