[CMake] installing dependents

David Cole david.cole at kitware.com
Mon Jul 20 13:51:30 EDT 2009 

On Mon, Jul 20, 2009 at 1:39 PM, Clinton Stimpson <clinton at elemtech.com>wrote:

>
> Thanks.  Do you know if gp_resolve_item handles 64 and 32 bit binaries
> correctly on Windows?


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
"gp_resolve_item_override" 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...

(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're hoping to achieve here though.)

Keep up the good work! Sounds like you are making progress on this stuff...
:-)


David




>
> "dumpbin /dependents" is used and it doesn't return full paths like ldd
> does on Linux, or otool on Mac.
> I put both in my PATH, so I can run both 32 and 64 bit programs.  I just
> wanted to make sure I was getting the right .dll when I copy it into my
> installation directory.
>
> Clint
>
> David Cole wrote:
>
>> On Fri, Jul 17, 2009 at 6:48 PM, David Cole <david.cole at kitware.com<mailto:
>> david.cole at kitware.com>> wrote:
>>
>>    No. It's supposed to return the actual string that is referenced
>>    by the thing being analyzed. But you can call gp_resolve_item to
>>    get the full path... (There is a reason for this, although I can't
>>    remember what it is at the moment... If I think of it, I'll reply
>>    again.)
>>
>>
>> I thought of/remembered the reason, so I'm replying again:
>>
>> The get_prerequisites function needs to return items exactly as they are
>> referenced in the executable being analyzed such that ...... later on, the
>> caller can use that string as an input to install_name_tool for replacing it
>> with something like "@executable_path/...." -- if the item were returned
>> resolved, then we would have to re-analyze the executable later to figure
>> out which string in the otool output corresponds to the resolved item... (Or
>> keep a map of them around, as is done in BundleUtilities...)
>>
>>
>>
>>
>>    From commentary in the middle of the get_prerequisites function:
>>
>>        # Use the raw_item as the list entries returned by this
>>    function. Use the
>>        # gp_resolve_item function to resolve it to an actual full
>>    path file if
>>        # necessary.
>>        #
>>        set(item "${raw_item}")
>>
>>
>>    HTH,
>>    David
>>
>>
>>    On Fri, Jul 17, 2009 at 6:40 PM, Clinton Stimpson
>>    <clinton at elemtech.com <mailto:clinton at elemtech.com>> wrote:
>>
>>
>>        Is get_prerequisites() supposed to return absolute paths all
>>        the time?
>>        For example, on the Mac, I've got some frameworks in
>>        /Library/Frameworks that I may want to copy if they might not
>>        exist on other Macs.  When I call get_prerequisites(), getting
>>        "foo.framwork/" instead of "/Library/Frameworks/foo.framework/"
>>
>>        Clint
>>
>>        David Cole wrote:
>>
>>            So I would love to see a corollary to
>>            BundleUtilities.cmake for Mac on Windows and Linux, too.
>>
>>            Using GetPrerequisites to gather the set of dependent
>>            files is obviously the first step.
>>
>>            Then, on Windows, a function that installs all the
>>            dependent dlls to the same location as the executable
>>            would be awesome.
>>
>>            On Linux, I guess you would have to make sure everything
>>            you depend on is either already installed in its install
>>            path, or aware of your install path, or uses
>>            LD_LIBRARY_PATH -- the issues here are the ones I am least
>>            familiar with (compared to Windows and Mac anyhow).
>>
>>            I don't think this should ever be fully automated because
>>            of licensing and coyright issues. Technically, it is easy
>>            to gather the set of required files to make something work
>>            on a practical level. The issue will be: "hey, you're not
>>            allowed to copy *that* dll" because of such and such
>>            non-technical reason...
>>
>>            Having said all this, and that I would love to see it, I
>>            must admit: it is not presently on the radar for any CMake
>>            developers as far as I know. So, as always: patches
>>            welcome. :-)
>>
>>
>>            HTH,
>>            David
>>
>>
>>            On Fri, Jul 17, 2009 at 3:05 PM, Clinton Stimpson
>>            <clinton at elemtech.com <mailto:clinton at elemtech.com>
>>            <mailto:clinton at elemtech.com
>>
>>            <mailto:clinton at elemtech.com>>> wrote:
>>
>>               So I'm using GetPrequisites.cmake to gather dependencies.
>>               Are there any examples, tips, etc.. for using this?
>>
>>               With the results I'm getting back, I do a
>>               file(INSTALL ... ) because that's what I see in the
>>               cmake_installcmake file.  Should it be documented?
>>               But these files I'm getting back are soft links to the real
>>               library.  And the file(INSTALL ... ) just puts a
>>            softlink in my
>>               installation directory instead of a real library.
>>
>>               Is there some higher level cmake function I should be
>>            calling to
>>               install libraries on Unix/Linux, similar to how there is
>>               BundleUtilties.cmake for Mac?  Or ideally, is there one
>>            function I
>>               can use on all platforms to install some prerequisites?
>>
>>               Thanks,
>>               Clint
>>
>>               _______________________________________________
>>               Powered by www.kitware.com <http://www.kitware.com>
>>            <http://www.kitware.com>
>>
>>
>>               Visit other Kitware open-source projects at
>>               http://www.kitware.com/opensource/opensource.html
>>
>>               Please keep messages on-topic and check the CMake FAQ at:
>>               http://www.cmake.org/Wiki/CMake_FAQ
>>
>>               Follow this link to subscribe/unsubscribe:
>>               http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>>
>>        _______________________________________________
>>        Powered by www.kitware.com <http://www.kitware.com>
>>
>>        Visit other Kitware open-source projects at
>>        http://www.kitware.com/opensource/opensource.html
>>
>>        Please keep messages on-topic and check the CMake FAQ at:
>>        http://www.cmake.org/Wiki/CMake_FAQ
>>
>>        Follow this link to subscribe/unsubscribe:
>>        http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090720/280aa06b/attachment.htm>

More information about the CMake mailing list