[CMake] installing dependents
David Cole
david.cole at kitware.com
Mon Jul 20 15:42:59 EDT 2009
On Mon, Jul 20, 2009 at 2:12 PM, Clinton Stimpson <clinton at elemtech.com>wrote:
>
> Would the general cmake solution for find_program/find_library do something
> like this:
> dumpbin /headers {some.lib|some.dll|some.exe} | findstr "machine" ?
> I get either AMD64 or x86 in the output from that.
Yes. Or something that's equivalent... More likely something that's
equivalent because I don't think a hard dependency on dumpbin to provide
core cmake functionality is such a good idea.
But... it also has to know which one you want. That's the more difficult
part of the problem. Either we have to add args to the signature of
find_program that says "only give me 64-bit results" (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 "real" solution -- inferring things is
always a bit dicey.
It's also more general than Win32 / Win64 -- if you are doing "FIND_LIBRARY"
stuff, you want the libraries found to match the architecture of the thing
you're building. Same thing applies to 32/64 on Linux and Mac and even
ppc/intel on Mac ... and cross compiling and ... It's just a can of worms
we have not opened yet.
>
> If find_program did it right, then gp_resolve_item would give me the right
> .dll file.
>
> Clint
>
> David Cole wrote:
>
>> On Mon, Jul 20, 2009 at 1:39 PM, Clinton Stimpson <clinton at elemtech.com<mailto:
>> 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>
>> <mailto: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>
>> <mailto: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>>
>> <mailto: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>
>> <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>
>> <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/10dc6796/attachment.htm>
More information about the CMake
mailing list