[CMake] creating <Package>Config.cmake and the LOCATION property

Server Levent Yilmaz leventyilmaz at gmail.com
Fri Sep 12 14:22:18 EDT 2008


On Tue, Sep 9, 2008 at 3:31 PM, Brad King <brad.king at kitware.com> wrote:
> Server Levent Yilmaz wrote:
>>
>> I have an outdated version of "Mastering CMake" book (for CMake version
>> 2.2).   Referring to section 6.7 "Creating a <Package>Config.cmake
>> file",  the configure step contains the following:
>>
>> GET_TARGET_PROPERTY( GROMIT_LIBRARY Gromit LOCATION )
>>
>> where Gromit is the library target and GROMIT_LIBRARY is the variable to
>> be used by CONFIGURE_FILE(  GromitConfig.cmake.in
>> <http://GromitConfig.cmake.in>  ... ) command. The problem is that the
>> LOCATION property is deprecated in CMake 2.6 (see
>> http://www.cmake.org/HTML/cmake-2.6.html#prop_tgt:LOCATION ), for
>> reasons which seems to exclude this particular use.
>>
>> So, what is the correct way to create config files for a library project?
>
> A totally new packaging mechanism has been implemented since the book
> was printed.  It is available in CMake 2.6.  The documentation is online
> here:
>
> http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_Targets
> http://www.cmake.org/Wiki/CMake_2.6_Notes#Packages
>
> -Brad
>

Thank you Brad, I implemented this new mechanism. It is really convenient
and works well. But I have a problem with my multi-project workspace. I'll
try to lay it down as succinctly as possible. Let the directory structure
be:

/workspace
| lib1
| lib2
| app1

Here lib1 and lib2 are libraries useful on their own, and are being used by
application app1. Each one of these three projects have separate
CMakeLists.txt and with this new Packaging/Export/Import mechanism, it is
very convenient to build and install these SEPARATELY.

But, in a scenario where these projects are developed simultaneously, it is
convenient to have a global workspace CMakeLists.txt, and use build-tree
exports:

#
# file: /workspace/CMakeLists.txt
#
project( mywork CXX C Fortran )
cmake_minimum_required(VERSION 2.6)
set( lib1_DIR ${PROJECT_BINARY_DIR}/lib1 )
set( lib2_DIR ${PROJECT_BINARY_DIR}/lib2 )
add_subdirectory( lib1 )
add_subdirectory( lib2 )
add_subdirectory( app1 )

And for example in lib1, in addition to install(TARGET ...) install(EXPORT
...) commands we have:

export(TARGETS lib1 FILE lib1-targets.cmake )

And in app1 we simply have

find_package( lib1 )
target_link_libraries( app1 lib1 )
include_directories( ${lib1_INCLUDE_DIR} )
# etc ...

Again, this works very well with separate builds/installations. But when
app1 is built as a part of the workspace/CMakeLists.txt  cmake gives the
following error:

CMake Error at build/lib1/lib1-targets.cmake:16 (ADD_LIBRARY):
  add_library cannot create imported target "lib1" because another target
  with the same name already exists.

Straightforward workarounds to this generate bunch of other problems but I
will not get into those right now. Hopefully we can discuss more.

Any suggestions, even in the form "dude, you got it all wrong. This is not
the way it's supposed to work", would be appreciated.


Levent


-- 
Server Levent Yilmaz
Mechanical Engineering
University of Pittsburgh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20080912/d6c3bf31/attachment.htm>


More information about the CMake mailing list