Re: [CMake] Package installation conundrum
Thanks, everybody, for your help. Eventually the CMake expert I've been
working with became available again and he solved the problem easily.
Cheers,
on Wed May 09 2012, Michael Wild
wrote:
> On 05/08/2012 11:13 PM, Dave Abrahams wrote:
>>
>> on Tue May 08 2012, Alexander Neundorf
>> wrote:
>>
>>> On Tuesday 08 May 2012, Dave Abrahams wrote:
>>>
>
Here's another one!
Scenario:
* I am running CMake under 0install to build and install libraries
* Each library builds a package SomePackage for the library binaries
and another package SomePackage-dev for the library headers (and
import libraries on Windows)
* The FindSomePackage.cmake file is part of the -dev package
* After building, 0install moves each package's build products into a
mostly-unpredictable subdirectory of its otherwise-read-only "cache"
(~/.cache/0install.net/). The subdirectory's name is determined by a
hash of the files.
* To get this working, I followed the scheme discussed here:
http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.l
uannocracy.com%3e
Summary:
1. Create a 0install "SomePackage-preinstall" package. Building this
package involves CMake building and installing both SomePackage and
SomePackage-dev into separate subdirectories (main/ and dev/) of
some prefix. 0install thereafter moves the whole directory tree
into its cache in a directory called sha1=someuglyhash
2. SomePackage's 0installation procedure is to copy
sha1=someuglyhash/main/ into its distribution directory (which then ends
up in
~/.cache/0install.net/sha1=otheruglyhash)
3. SomePackage-dev's 0installation procedure is to copy
sha1=someuglyhash/dev/ into its distribution directory
Problem: FindSomePackageConfig.cmake now has the wrong path to the
library binaries.
Any help most appreciated.
>>>
>>> Can you please summarize what you actually want to achieve ?
>>
>> Well, I tried to, above.
>>
>> In short, I want to create separate main and -dev packages without
>> building twice, under the constraints imposed by 0install.
>>
>>> Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel ?
>>>
>>> If that's the case, then this is wrong.
>>
>> I'm sorry, that *is* wrong. It installs a FooConfig.cmake as part of
>> libFoo.devel
>>
>>> FindFoo.cmake must be part of the using software, not of the software to be
>>> searched.
>>>
>>> Why do you have to find the installed library in this cache directory
>>> ?
>>
>> Because, in a 0install world, that's where things go when you "install"
>> them.
>>
>
> Ok, how you do it along these lines:
>
> CMakeLists.txt:
> #-- BOF
>
> cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
> project(Foo)
>
> set(FOO_VERSION 1.2.3)
>
> # initialize (absolute) installation directory variables
> set(INSTALL_BIN_DIR bin CACHE PATH "Install path for binaries")
> set(INSTALL_LIB_DIR lib CACHE PATH "Install path for libraries")
> set(INSTALL_INCLUDE_DIR include CACHE PATH "Install path for headers")
> # this is for UNIX systems, see docs of find_package() for the search
> # paths on APPLE and WIN32
> set(INSTALL_CMAKE_DIR lib/foo-${FOO_VERSION}/cmake CACHE PATH
> "Install path for CMake files")
> foreach(t BIN LIB INCLUDE CMAKE)
> if(NOT IS_ABSOLUTE ${INSTALL_${t}_DIR})
> set(INSTALL_${t}_DIR ${CMAKE_INSTALL_PREFIX}/${INSTALL_${t}_DIR})
> endif()
> mark_as_advanced(INSTALL_${t}_DIR)
> endforeach()
>
> # configure FooConfig.cmake and friends. FooConfig.cmake must be able
> # to locate FooExports.cmake and FOO_INCLUDE_DIR relative to its own
> # directory without using absolute paths.
> configure_file(cmake/FooConfig.cmake.in
> ${PROJECT_BINARY_DIR}/FooConfig.cmake @ONLY)
> configure_file(cmake/FooConfigVersion.cmake.in
> ${PROJECT_BINARY_DIR}/FooConfigVersion.cmake @ONLY)
>
> # configure the headers into the build tree so the package can be used
> # without installing it and not hard-coding the source/build directory
> # information into FooConfig.cmake
> configure_file(include/foo.h
> ${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)
>
> # build targets
> add_library(foo src/foo.cpp include/foo.h)
> set_target_properties(foo PROPERTIES
> PUBLIC_HEADER include/foo.h
> VERSION ${FOO_VERSION}
> SOVERSION 1.0)
> add_executable(bar bar.cpp)
> target_link_libraries(bar foo)
>
> # install targets and files
> install(TARGETS foo bar
> EXPORT FooExports
> RUNTIME DESTINATION ${INSTALL_BIN_DIR} COMPONENT bin
> LIBRARY DESTINATION ${INSTALL_LIB_DIR} COMPONENT bin
> ARCHIVE DESTINATION ${INSTALL_LIB_DIR} COMPONENT dev
> PUBLIC_HEADER DESTINATION ${INSTALL_INCLUDE_DIR} COMPONENT dev)
>
> install(FILES
> ${PROJECT_BINARY_DIR}/FooConfig.cmake
> ${PROJECT_BINARY_DIR}/FooConfigVersion.cmake
> DESTINATION ${INSTALL_CMAKE_DIR} COMPONENT dev)
>
> # export targets to bui
Re: [CMake] Package installation conundrum
On Wed, May 9, 2012 at 4:01 PM, Alexander Neundorf
wrote:
> On Wednesday 09 May 2012, Michael Wild wrote:
>
>> On 09.05.2012, at 21:03, Alexander Neundorf
>> wrote:
>
> ...
>
>> > > # configure the headers into the build tree so the package can be used
>
>> > > # without installing it and not hard-coding the source/build directory
>
>> > > # information into FooConfig.cmake
>
>> > > configure_file(include/foo.h
>
>> > > ${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)
>
>> >
>
>> > The input file should have a suffix which indicates it is a file which
>> > is
>
>> > intended to be configured, usually foo.h.in. Alex
>
>>
>
>> I don't agree, since it's COPYONLY. Besides, with a little more work in
>
>> FooConfig.cmake you can skip that step...
>
> Oh, sorry, I missed the COPYONLY.
>
> Alex
>
>
> --
>
> 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://www.cmake.org/mailman/listinfo/cmake
FYI -- I know we discourage in-source builds heavily but -- we do
still support them, so:
And in such a case where the source and build trees are the same, it's
still important to use a .in extension (or something) on the input
file to make it different from the output file.
Use a .in extension on configure_file inputs unless you also have code
in place to prohibit in-source builds.
David
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Package installation conundrum
On Wednesday 09 May 2012, Michael Wild wrote:
> On 09.05.2012, at 21:03, Alexander Neundorf wrote:
...
> > > # configure the headers into the build tree so the package can be used
> > > # without installing it and not hard-coding the source/build directory
> > > # information into FooConfig.cmake
> > > configure_file(include/foo.h
> > > ${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)
> >
> > The input file should have a suffix which indicates it is a file which is
> > intended to be configured, usually foo.h.in. Alex
>
> I don't agree, since it's COPYONLY. Besides, with a little more work in
> FooConfig.cmake you can skip that step...
Oh, sorry, I missed the COPYONLY.
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Package installation conundrum
On 09.05.2012, at 21:03, Alexander Neundorf wrote:
> On Wednesday 09 May 2012, Michael Wild wrote:
> > On 05/08/2012 11:13 PM, Dave Abrahams wrote:
> > > on Tue May 08 2012, Alexander Neundorf
> > > wrote:
> > >> On Tuesday 08 May 2012, Dave Abrahams wrote:
> > >>> Here's another one!
> > >>>
> > >>> Scenario:
> > >>>
> > >>> * I am running CMake under 0install to build and install libraries
> > >>>
> > >>> * Each library builds a package SomePackage for the library binaries
> > >>> and another package SomePackage-dev for the library headers (and
> > >>> import libraries on Windows)
> > >>>
> > >>> * The FindSomePackage.cmake file is part of the -dev package
> > >>>
> > >>> * After building, 0install moves each package's build products into a
> > >>> mostly-unpredictable subdirectory of its otherwise-read-only "cache"
> > >>> (~/.cache/0install.net/). The subdirectory's name is determined by a
> > >>> hash of the files.
> > >>>
> > >>> * To get this working, I followed the scheme discussed here:
> > >>>
> > >>> http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40plut
> > >>> o.l uannocracy.com%3e
> > >>>
> > >>> Summary:
> > >>>
> > >>> 1. Create a 0install "SomePackage-preinstall" package. Building this
> > >>> package involves CMake building and installing both SomePackage and
> > >>> SomePackage-dev into separate subdirectories (main/ and dev/) of
> > >>> some prefix. 0install thereafter moves the whole directory tree
> > >>> into its cache in a directory called sha1=someuglyhash
> > >>>
> > >>> 2. SomePackage's 0installation procedure is to copy
> > >>> sha1=someuglyhash/main/ into its distribution directory (which then
> > >>> ends up in
> > >>> ~/.cache/0install.net/sha1=otheruglyhash)
> > >>>
> > >>> 3. SomePackage-dev's 0installation procedure is to copy
> > >>> sha1=someuglyhash/dev/ into its distribution directory
> > >>>
> > >>> Problem: FindSomePackageConfig.cmake now has the wrong path to the
> > >>> library binaries.
> > >>>
> > >>> Any help most appreciated.
> > >>
> > >> Can you please summarize what you actually want to achieve ?
> > >
> > > Well, I tried to, above.
> > >
> > > In short, I want to create separate main and -dev packages without
> > > building twice, under the constraints imposed by 0install.
> > >
> > >> Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel
> > >> ?
> > >>
> > >> If that's the case, then this is wrong.
> > >
> > > I'm sorry, that *is* wrong. It installs a FooConfig.cmake as part of
> > > libFoo.devel
> > >
> > >> FindFoo.cmake must be part of the using software, not of the software to
> > >> be searched.
> > >>
> > >> Why do you have to find the installed library in this cache directory
> > >> ?
> > >
> > > Because, in a 0install world, that's where things go when you "install"
> > > them.
> >
> > Ok, how you do it along these lines:
> >
> > CMakeLists.txt:
> > #-- BOF
> >
> > cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
> > project(Foo)
> >
> > set(FOO_VERSION 1.2.3)
> >
> > # initialize (absolute) installation directory variables
> > set(INSTALL_BIN_DIR bin CACHE PATH "Install path for binaries")
> > set(INSTALL_LIB_DIR lib CACHE PATH "Install path for libraries")
> > set(INSTALL_INCLUDE_DIR include CACHE PATH "Install path for headers")
> > # this is for UNIX systems, see docs of find_package() for the search
> > # paths on APPLE and WIN32
> > set(INSTALL_CMAKE_DIR lib/foo-${FOO_VERSION}/cmake CACHE PATH
> > "Install path for CMake files")
> > foreach(t BIN LIB INCLUDE CMAKE)
> > if(NOT IS_ABSOLUTE ${INSTALL_${t}_DIR})
> > set(INSTALL_${t}_DIR ${CMAKE_INSTALL_PREFIX}/${INSTALL_${t}_DIR})
> > endif()
> > mark_as_advanced(INSTALL_${t}_DIR)
> > endforeach()
> >
> > # configure FooConfig.cmake and friends. FooConfig.cmake must be able
> > # to locate FooExports.cmake and FOO_INCLUDE_DIR relative to its own
> > # directory without using absolute paths.
> > configure_file(cmake/FooConfig.cmake.in
> > ${PROJECT_BINARY_DIR}/FooConfig.cmake @ONLY)
> Please have a lokok at the new macro configure_package_config_file() which is
> in cmake 2.8.8.
> This helps a lot with writing config files which are relocatable.
> The Config.cmake.in file has to contains a few special variables/macros:
> @PACKAGE_INIT@
> set(FOO_INCLUDE_DIR "@PACKAGE_INSTALL_INCLUDE_DIR@" )
> set(FOO_BIN_DIR "@PACKAGE_INSTALL_BIN_DIR@" )
> i.e. for every FOO_XYZ variable use a @PACKAGE_FOO_XYZ@ variable, and the
> configure_package_config_file() will replace this with the help of the
> @PACKAGE_INIT@ macro with a relocatable version.
> http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:CMakePackageConfigHelpers
> > configure_file(cmake/FooConfigVersion.cmake.in
> > ${PROJECT_BINARY_DIR}/FooConfigVersion.cmake @ONLY)
> >
> > # configure the headers into the build tree so the package can be used
> > # without installing it and not hard-coding the source/build directory
> > # information into FooConfig.cmake
> > configure_file(include/foo.h
Re: [CMake] Package installation conundrum
On Wednesday 09 May 2012, Michael Wild wrote:
> On 05/08/2012 11:13 PM, Dave Abrahams wrote:
> > on Tue May 08 2012, Alexander Neundorf wrote:
> >> On Tuesday 08 May 2012, Dave Abrahams wrote:
> >>> Here's another one!
> >>>
> >>> Scenario:
> >>>
> >>> * I am running CMake under 0install to build and install libraries
> >>>
> >>> * Each library builds a package SomePackage for the library binaries
> >>> and another package SomePackage-dev for the library headers (and
> >>> import libraries on Windows)
> >>>
> >>> * The FindSomePackage.cmake file is part of the -dev package
> >>>
> >>> * After building, 0install moves each package's build products into a
> >>> mostly-unpredictable subdirectory of its otherwise-read-only "cache"
> >>> (~/.cache/0install.net/). The subdirectory's name is determined by a
> >>> hash of the files.
> >>>
> >>> * To get this working, I followed the scheme discussed here:
> >>>
> >>> http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40plut
> >>> o.l uannocracy.com%3e
> >>>
> >>> Summary:
> >>>
> >>> 1. Create a 0install "SomePackage-preinstall" package. Building this
> >>> package involves CMake building and installing both SomePackage and
> >>> SomePackage-dev into separate subdirectories (main/ and dev/) of
> >>> some prefix. 0install thereafter moves the whole directory tree
> >>> into its cache in a directory called sha1=someuglyhash
> >>>
> >>> 2. SomePackage's 0installation procedure is to copy
> >>> sha1=someuglyhash/main/ into its distribution directory (which then
> >>> ends up in
> >>> ~/.cache/0install.net/sha1=otheruglyhash)
> >>>
> >>> 3. SomePackage-dev's 0installation procedure is to copy
> >>> sha1=someuglyhash/dev/ into its distribution directory
> >>>
> >>> Problem: FindSomePackageConfig.cmake now has the wrong path to the
> >>> library binaries.
> >>>
> >>> Any help most appreciated.
> >>
> >> Can you please summarize what you actually want to achieve ?
> >
> > Well, I tried to, above.
> >
> > In short, I want to create separate main and -dev packages without
> > building twice, under the constraints imposed by 0install.
> >
> >> Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel
> >> ?
> >>
> >> If that's the case, then this is wrong.
> >
> > I'm sorry, that *is* wrong. It installs a FooConfig.cmake as part of
> > libFoo.devel
> >
> >> FindFoo.cmake must be part of the using software, not of the software to
> >> be searched.
> >>
> >> Why do you have to find the installed library in this cache directory
> >> ?
> >
> > Because, in a 0install world, that's where things go when you "install"
> > them.
>
> Ok, how you do it along these lines:
>
> CMakeLists.txt:
> #-- BOF
>
> cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
> project(Foo)
>
> set(FOO_VERSION 1.2.3)
>
> # initialize (absolute) installation directory variables
> set(INSTALL_BIN_DIR bin CACHE PATH "Install path for binaries")
> set(INSTALL_LIB_DIR lib CACHE PATH "Install path for libraries")
> set(INSTALL_INCLUDE_DIR include CACHE PATH "Install path for headers")
> # this is for UNIX systems, see docs of find_package() for the search
> # paths on APPLE and WIN32
> set(INSTALL_CMAKE_DIR lib/foo-${FOO_VERSION}/cmake CACHE PATH
> "Install path for CMake files")
> foreach(t BIN LIB INCLUDE CMAKE)
> if(NOT IS_ABSOLUTE ${INSTALL_${t}_DIR})
> set(INSTALL_${t}_DIR ${CMAKE_INSTALL_PREFIX}/${INSTALL_${t}_DIR})
> endif()
> mark_as_advanced(INSTALL_${t}_DIR)
> endforeach()
>
> # configure FooConfig.cmake and friends. FooConfig.cmake must be able
> # to locate FooExports.cmake and FOO_INCLUDE_DIR relative to its own
> # directory without using absolute paths.
> configure_file(cmake/FooConfig.cmake.in
> ${PROJECT_BINARY_DIR}/FooConfig.cmake @ONLY)
Please have a lokok at the new macro configure_package_config_file() which is
in cmake 2.8.8.
This helps a lot with writing config files which are relocatable.
The Config.cmake.in file has to contains a few special variables/macros:
@PACKAGE_INIT@
set(FOO_INCLUDE_DIR "@PACKAGE_INSTALL_INCLUDE_DIR@" )
set(FOO_BIN_DIR "@PACKAGE_INSTALL_BIN_DIR@" )
i.e. for every FOO_XYZ variable use a @PACKAGE_FOO_XYZ@ variable, and the
configure_package_config_file() will replace this with the help of the
@PACKAGE_INIT@ macro with a relocatable version.
http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:CMakePackageConfigHelpers
> configure_file(cmake/FooConfigVersion.cmake.in
> ${PROJECT_BINARY_DIR}/FooConfigVersion.cmake @ONLY)
>
> # configure the headers into the build tree so the package can be used
> # without installing it and not hard-coding the source/build directory
> # information into FooConfig.cmake
> configure_file(include/foo.h
> ${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)
The input file should have a suffix which indicates it is a file which is
intended to be configured, usually foo.h.in.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source proje
Re: [CMake] Package installation conundrum
On 05/08/2012 11:13 PM, Dave Abrahams wrote:
>
> on Tue May 08 2012, Alexander Neundorf
> wrote:
>
>> On Tuesday 08 May 2012, Dave Abrahams wrote:
>>
>>> Here's another one!
>>>
>>> Scenario:
>>>
>>> * I am running CMake under 0install to build and install libraries
>>>
>>> * Each library builds a package SomePackage for the library binaries
>>> and another package SomePackage-dev for the library headers (and
>>> import libraries on Windows)
>>>
>>> * The FindSomePackage.cmake file is part of the -dev package
>>>
>>> * After building, 0install moves each package's build products into a
>>> mostly-unpredictable subdirectory of its otherwise-read-only "cache"
>>> (~/.cache/0install.net/). The subdirectory's name is determined by a
>>> hash of the files.
>>>
>>> * To get this working, I followed the scheme discussed here:
>>>
>>> http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.l
>>> uannocracy.com%3e
>>>
>>> Summary:
>>>
>>> 1. Create a 0install "SomePackage-preinstall" package. Building this
>>> package involves CMake building and installing both SomePackage and
>>> SomePackage-dev into separate subdirectories (main/ and dev/) of
>>> some prefix. 0install thereafter moves the whole directory tree
>>> into its cache in a directory called sha1=someuglyhash
>>>
>>> 2. SomePackage's 0installation procedure is to copy
>>> sha1=someuglyhash/main/ into its distribution directory (which then ends
>>> up in
>>> ~/.cache/0install.net/sha1=otheruglyhash)
>>>
>>> 3. SomePackage-dev's 0installation procedure is to copy
>>> sha1=someuglyhash/dev/ into its distribution directory
>>>
>>> Problem: FindSomePackageConfig.cmake now has the wrong path to the
>>> library binaries.
>>>
>>> Any help most appreciated.
>>
>> Can you please summarize what you actually want to achieve ?
>
> Well, I tried to, above.
>
> In short, I want to create separate main and -dev packages without
> building twice, under the constraints imposed by 0install.
>
>> Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel ?
>>
>> If that's the case, then this is wrong.
>
> I'm sorry, that *is* wrong. It installs a FooConfig.cmake as part of
> libFoo.devel
>
>> FindFoo.cmake must be part of the using software, not of the software to be
>> searched.
>>
>> Why do you have to find the installed library in this cache directory
>> ?
>
> Because, in a 0install world, that's where things go when you "install"
> them.
>
Ok, how you do it along these lines:
CMakeLists.txt:
#-- BOF
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(Foo)
set(FOO_VERSION 1.2.3)
# initialize (absolute) installation directory variables
set(INSTALL_BIN_DIR bin CACHE PATH "Install path for binaries")
set(INSTALL_LIB_DIR lib CACHE PATH "Install path for libraries")
set(INSTALL_INCLUDE_DIR include CACHE PATH "Install path for headers")
# this is for UNIX systems, see docs of find_package() for the search
# paths on APPLE and WIN32
set(INSTALL_CMAKE_DIR lib/foo-${FOO_VERSION}/cmake CACHE PATH
"Install path for CMake files")
foreach(t BIN LIB INCLUDE CMAKE)
if(NOT IS_ABSOLUTE ${INSTALL_${t}_DIR})
set(INSTALL_${t}_DIR ${CMAKE_INSTALL_PREFIX}/${INSTALL_${t}_DIR})
endif()
mark_as_advanced(INSTALL_${t}_DIR)
endforeach()
# configure FooConfig.cmake and friends. FooConfig.cmake must be able
# to locate FooExports.cmake and FOO_INCLUDE_DIR relative to its own
# directory without using absolute paths.
configure_file(cmake/FooConfig.cmake.in
${PROJECT_BINARY_DIR}/FooConfig.cmake @ONLY)
configure_file(cmake/FooConfigVersion.cmake.in
${PROJECT_BINARY_DIR}/FooConfigVersion.cmake @ONLY)
# configure the headers into the build tree so the package can be used
# without installing it and not hard-coding the source/build directory
# information into FooConfig.cmake
configure_file(include/foo.h
${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)
# build targets
add_library(foo src/foo.cpp include/foo.h)
set_target_properties(foo PROPERTIES
PUBLIC_HEADER include/foo.h
VERSION ${FOO_VERSION}
SOVERSION 1.0)
add_executable(bar bar.cpp)
target_link_libraries(bar foo)
# install targets and files
install(TARGETS foo bar
EXPORT FooExports
RUNTIME DESTINATION ${INSTALL_BIN_DIR} COMPONENT bin
LIBRARY DESTINATION ${INSTALL_LIB_DIR} COMPONENT bin
ARCHIVE DESTINATION ${INSTALL_LIB_DIR} COMPONENT dev
PUBLIC_HEADER DESTINATION ${INSTALL_INCLUDE_DIR} COMPONENT dev)
install(FILES
${PROJECT_BINARY_DIR}/FooConfig.cmake
${PROJECT_BINARY_DIR}/FooConfigVersion.cmake
DESTINATION ${INSTALL_CMAKE_DIR} COMPONENT dev)
# export targets to build and install tree
export(TARGETS foo bar NAMESPACE Foo_
FILE ${PROJECT_BINARY_DIR}/FooExports.cmake)
export(PACKAGE Foo)
install(EXPORT FooExports
DESTINATION ${INSTALL_CMAKE_DIR}
NAMESPACE Foo_
COMPONENT dev)
#-- EOF
With such a setup, you do something like the following for the
installation into the cache directories:
mkdir /path/to/build-tree
cd /path/to/
Re: [CMake] Package installation conundrum
on Tue May 08 2012, Alexander Neundorf wrote: > On Tuesday 08 May 2012, Dave Abrahams wrote: > >> Here's another one! >> >> Scenario: >> >> * I am running CMake under 0install to build and install libraries >> >> * Each library builds a package SomePackage for the library binaries >> and another package SomePackage-dev for the library headers (and >> import libraries on Windows) >> >> * The FindSomePackage.cmake file is part of the -dev package >> >> * After building, 0install moves each package's build products into a >> mostly-unpredictable subdirectory of its otherwise-read-only "cache" >> (~/.cache/0install.net/). The subdirectory's name is determined by a >> hash of the files. >> >> * To get this working, I followed the scheme discussed here: >> >> http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.l >> uannocracy.com%3e >> >> Summary: >> >> 1. Create a 0install "SomePackage-preinstall" package. Building this >> package involves CMake building and installing both SomePackage and >> SomePackage-dev into separate subdirectories (main/ and dev/) of >> some prefix. 0install thereafter moves the whole directory tree >> into its cache in a directory called sha1=someuglyhash >> >> 2. SomePackage's 0installation procedure is to copy >> sha1=someuglyhash/main/ into its distribution directory (which then ends >> up in >> ~/.cache/0install.net/sha1=otheruglyhash) >> >> 3. SomePackage-dev's 0installation procedure is to copy >> sha1=someuglyhash/dev/ into its distribution directory >> >> Problem: FindSomePackageConfig.cmake now has the wrong path to the >> library binaries. >> >> Any help most appreciated. > > Can you please summarize what you actually want to achieve ? Well, I tried to, above. In short, I want to create separate main and -dev packages without building twice, under the constraints imposed by 0install. > Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel ? > > If that's the case, then this is wrong. I'm sorry, that *is* wrong. It installs a FooConfig.cmake as part of libFoo.devel > FindFoo.cmake must be part of the using software, not of the software to be > searched. > > Why do you have to find the installed library in this cache directory > ? Because, in a 0install world, that's where things go when you "install" them. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Package installation conundrum
On Tuesday 08 May 2012, Dave Abrahams wrote: > Here's another one! > > Scenario: > > * I am running CMake under 0install to build and install libraries > > * Each library builds a package SomePackage for the library binaries > and another package SomePackage-dev for the library headers (and > import libraries on Windows) > > * The FindSomePackage.cmake file is part of the -dev package > > * After building, 0install moves each package's build products into a > mostly-unpredictable subdirectory of its otherwise-read-only "cache" > (~/.cache/0install.net/). The subdirectory's name is determined by a > hash of the files. > > * To get this working, I followed the scheme discussed here: > > http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.l > uannocracy.com%3e > > Summary: > > 1. Create a 0install "SomePackage-preinstall" package. Building this > package involves CMake building and installing both SomePackage and > SomePackage-dev into separate subdirectories (main/ and dev/) of > some prefix. 0install thereafter moves the whole directory tree > into its cache in a directory called sha1=someuglyhash > > 2. SomePackage's 0installation procedure is to copy > sha1=someuglyhash/main/ into its distribution directory (which then ends > up in > ~/.cache/0install.net/sha1=otheruglyhash) > > 3. SomePackage-dev's 0installation procedure is to copy > sha1=someuglyhash/dev/ into its distribution directory > > Problem: FindSomePackageConfig.cmake now has the wrong path to the > library binaries. > > Any help most appreciated. Can you please summarize what you actually want to achieve ? Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel ? If that's the case, then this is wrong. FindFoo.cmake must be part of the using software, not of the software to be searched. Why do you have to find the installed library in this cache directory ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Package installation conundrum
Here's another one! Scenario: * I am running CMake under 0install to build and install libraries * Each library builds a package SomePackage for the library binaries and another package SomePackage-dev for the library headers (and import libraries on Windows) * The FindSomePackage.cmake file is part of the -dev package * After building, 0install moves each package's build products into a mostly-unpredictable subdirectory of its otherwise-read-only "cache" (~/.cache/0install.net/). The subdirectory's name is determined by a hash of the files. * To get this working, I followed the scheme discussed here: http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.luannocracy.com%3e Summary: 1. Create a 0install "SomePackage-preinstall" package. Building this package involves CMake building and installing both SomePackage and SomePackage-dev into separate subdirectories (main/ and dev/) of some prefix. 0install thereafter moves the whole directory tree into its cache in a directory called sha1=someuglyhash 2. SomePackage's 0installation procedure is to copy sha1=someuglyhash/main/ into its distribution directory (which then ends up in ~/.cache/0install.net/sha1=otheruglyhash) 3. SomePackage-dev's 0installation procedure is to copy sha1=someuglyhash/dev/ into its distribution directory Problem: FindSomePackageConfig.cmake now has the wrong path to the library binaries. Any help most appreciated. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- 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://www.cmake.org/mailman/listinfo/cmake
