[CMake] installing dependents
Clinton Stimpson
clinton at elemtech.com
Mon Jul 20 14:12:51 EDT 2009
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.
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
>
>
>
>
>
More information about the CMake
mailing list