On 2/16/2012 4:13 PM, David Cole wrote:
On Thu, Feb 16, 2012 at 3:52 PM, Eric Noulard <[email protected]
<mailto:[email protected]>> wrote:
I'm not convinced, yet I'll have to try with the example provided by Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
"${CMAKE_CURRENT_LIST_DIR}/../../../" ABSOLUTE)
[snip]
> It can't work with CPack, not in the sense of "work" as in "the
> software will run from its DESTDIR-based intermediate CPack
> driven install location"
It can. The main feature of what Alex wrote based on a combination
of his, Yury's, and my ideas is that the generated BarConfig.cmake has
no hard-coded paths containing the installation prefix in any form,
DESTDIR or not. The line
get_filename_component(BAR_HELPER_PREFIX_DIR
"${CMAKE_CURRENT_LIST_DIR}/../../../" ABSOLUTE)
is evaluated when BarConfig.cmake is *loaded* at which point the
${CMAKE_CURRENT_LIST_DIR} will be replaced with the *current* location
of the file as it exists when loaded. It doesn't matter if it is in
the real install location, DESTDIR, or a tarball that was extracted
at an arbitrary location on another machine. The load-time prefix
is computed relative to the file's location. Under that prefix the
file refers to all the other pieces (include, etc.) which exist at
a fixed location relative to BarConfig.cmake.
-Brad
--
Powered by 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
