|
(0033737)
|
|
Stephen Kelly
|
|
2013-08-20 12:04
|
|
This bug appears to be invalid and a result of using install(TARGETS) with an absolute path as the DESTINATION for the library.
[17:38:53] <steveire> Sput: ping?
[17:39:01] <Sput> steveire: pong
[17:39:12] <steveire> http://public.kitware.com/Bug/view.php?id=14367 [^] Can I get more info here?
[17:39:18] <Sput> sure, what do you need?
[17:39:22] <steveire> What value is the CMAKE_INSTALL_PREFIX?
[17:39:35] <steveire> and what's the sysroot, and where are the config files?
[17:39:36] <Sput> I think it's /usr
[17:39:53] <Sput> lemme see what I can add there
[17:40:00] <Sput> the use case is compiling cmake-based stuff on Yocto, btw.
[17:40:11] <Sput> which creates a toolchain file
[17:40:14] <steveire> So you set CMAKE_INSTALL_PREFIX to /usr and use DESTDIR to install to the sysroot or something?
[17:40:27] <Sput> no, I think we just use a toolchain file
[17:40:30] <Sput> lemme dig one out
[17:40:36] <steveire> creates a toolchain file? Where can I find out more about that?
[17:41:39] <Sput> so, this is basically the thing in Yocto that does all the magic:
[17:41:40] <Sput> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cmake.bbclass [^]
[17:42:14] <Sput> even without Yocto knowledge, it should be helpful for starters
[17:42:27] <Sput> in general, you have two sysroots - one for native host tools, and one for the target itself
[17:44:11] <Sput> ok, it uses DESTDIR after all (autotools_do_install is called)
[17:44:39] <steveire> Right. Otherwise, you'd end up with the installation in /usr on the host.
[17:44:49] <Sput> yep, thought there was some built-in magic for that
[17:45:52] <Sput> funnily enough, if I pass a PATH parameter through -D, the sysroot will be prepended for some reason
[17:46:55] <steveire> We discussed the idea of two prefixes here btw: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7292 [^]
[17:47:41] <Sput> aah, so proper sysroot support is work in progress? that's cool already
[17:48:02] <Sput> as the current way seems clunky in various ways
[17:48:02] <steveire> Yes, CMAKE_SYSROOT was merged but reverted for 2.8.12.
[17:48:18] <steveire> The branch lives in my clone at http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7292 [^]
[17:48:21] <Sput> e.g. the FIND_ROOT_PATH thingies don't apply to FooConfig.cmake files
[17:48:21] <steveire> git@gitorious.org:~steveire/cmake/steveires-cmake.git a
[17:48:23] <steveire> I mean
[17:48:49] <steveire> Yes, the plan is to fix all of the clunkiness in 2.8.13 hopefully
[17:49:02] <Sput> and in case of Qt5, we have to do some real fugly patching to overwrite the IMPORTED_LOCATION of the host tool targets (Qt5::moc and friends)
[17:49:34] <Sput> but this was solvable. I have no clue how to fix the problem of the export files now
[17:49:35] <steveire> Ok. I'd like to know more about that, but first I'd like to know more about the issue in the bug report.
[17:50:56] <Sput> ok. so we do install(EXPORT ...) which is supposed to generate a file containing all the targets
[17:51:06] <steveire> So, let's say that CMAKE_INSTALL_PREFIX is /usr, you have a sysroot at ~/sysroot, and you install a foo package there. Then you want to build the bar package. bar depends on foo, so it contains find_package(foo REQUIRED). Good so far?
[17:51:22] <Sput> yes
[17:52:04] <Sput> find_package works fine because FIND_ROOT_PATH does the right thing.
[17:52:07] <steveire> fooConfig.cmake include()s fooTargets.cmake, which include()s fooTargets-release.cmake, which uses the IMPORTED_LOCATION "${_IMPORT_PREFIX}/lib/libfoo.so", right?
[17:52:22] <Sput> indeed. and that's where it breaks.
[17:52:29] <Sput> because it's an absolute path
[17:52:34] <steveire> because of the value of _IMPORT_PREFIX ?
[17:52:40] <Sput> I don't actually think it used _IMPORT_PREFIX
[17:52:47] <steveire> It should :)
[17:53:00] <Sput> I wonder if I can dig out the file now somewhere (I disabled exporting for the time being)
[17:53:16] <steveire> cmake has generated IMPORTED_LOCATIONs using _IMPORT_PREFIX for at least a few releases I think.
[17:53:19] <Sput> I'm rather sure it was /usr/lib/whatever
[17:53:28] <steveire> Ok, please check.
[17:54:22] <steveire> Sput: Ah, actually the problem may be in the CMakeLists.txt of foo.
[17:54:53] <steveire> If it contains install(TARGETS foo DESTINATION "${CMAKE_INSTALL_PREFIX}/lib"), then cmake generates an absolute path.
[17:55:18] <Sput> install(EXPORT FooTargets DESTINATION "${INSTALL_CMAKE_DIR}" COMPONENT dev)
[17:55:19] <steveire> But if it contains DESTINATION "lib", then the 'lib' gets prefixed with ${_IMPORT_PREFIX}
[17:55:28] <Sput> where INSTALL_CMAKE_DIR is probably an absolute path
[17:55:45] <steveire> Not a problem. Look for the install(TARGETS) use
[17:55:50] <steveire> not install(EXPORT)
[17:56:41] <Sput> what do you mean?
[17:57:35] <Sput> install(
[17:57:35] <Sput> TARGETS Foo
[17:57:35] <Sput> EXPORT FooTargets RUNTIME DESTINATION "${INSTALL_BIN_DIR}" COMPONENT bin LIBRARY DESTINATION "${INSTALL_LIB_DIR}" COMPONENT shlib PUBLIC_HEADER DESTINATION "${INSTALL_INCLUDE_DIR}" COMPONENT dev
[17:57:35] <Sput> )
[17:57:43] <steveire> Exactly.
[17:57:55] <steveire> Is INSTALL_LIB_DIR an absolute path? Then that's the problem.
[17:57:55] <Sput> so how should I change this?
[17:58:02] <Sput> aaah
[17:58:15] <steveire> If you tell cmake to use an absolute path, then it will :)
[17:58:18] <Sput> I somehow overlooked that TARGETS three time in your previous statement :)
[17:59:01] <Sput> it's most probably an absolute path, yes (because somehow setting a VAR:PATH through -D prepends the sysroot, I still have no clue why)
[17:59:23] <Sput> that can be solved by overriding this with STRING
[17:59:35] <steveire> Ok. Can I paste this log in the cmake bug report anyway? The bug seems to be invalid.
[17:59:50] <Sput> so I'll try setting the library path to something relative next (probably tomorrow)
[18:00:24] <Sput> why doesn't the generated absolute path contain the sysroot?
[18:00:30] <Sput> if the variable is set to that...
[18:01:01] <steveire> I'm sure the generated absolute path is set to whatever is in the variable.
[18:01:05] <steveire> Ok. Can I paste this log in the cmake bug report anyway? The bug seems to be invalid.
[18:01:16] <Sput> you can do this, of course
[18:01:27] <Sput> I'll play around with that and try to verify tomorrow
[18:01:36] <Sput> might ping you again for questions :)
[18:01:45] <steveire> Ok :) |
|