MantisBT - CMake
View Issue Details
0013460CMakeCMakepublic2012-08-06 12:362015-07-08 08:57
Michael Tänzer 
Stephen Kelly 
normalfeaturealways
closedfixed 
Ubuntu Linux12.04
CMake 2.8.7 
CMake 3.0 
0013460: Use the same mechanism for export() as for install(EXPORT)
I have a CMake project that compiles some libraries statically or both shared and static if BUILD_SHARED_LIBS is set. In the second case another target called mylib_static is defined (BTW: would be cool if there was real support for these cases because as it is now it has to be compiled twice, but that's another story). myotherlib links to mylib.

The install(EXPORT) syntax is perfect because I just can define
install(TARGETS mylib ${mylib_static_TARGET} EXPORT myproject-targets)
in one subdir,
install(TARGETS myotherlib ${myotherlib_static_TARGET} EXPORT myproject-targets)
in the other subdir and
install(EXPORT myproject-targets)
in the top level directory and everything gets exported in just one cmake file.

Here comes the problem: if I use
export(TARGETS mylib ${mylib_static_TARGET} FILE mylib-exports.cmake)
in one subdir and
export(TARGETS myotherlib ${myotherlib_static_TARGET} mylib FILE myotherlib-exports.cmake)
in the other one (mylib is needed as CMake complains otherwise that the target myotherlib links to is not included in the export file). I can't just do the following in a myproject-config.cmake.in
include("@myproject_BINARY_DIR@/source/mylib/mylib-exports.cmake")
include("@myproject_BINARY_DIR@/source/myotherlib/myotherlib-exports.cmake")
because then the mylib target would be redefined.

I could do the exports in the top-level file but then I would have to edit it whenever a new library gets added (yeah, I know, I'm lazy) and also always propagate the <lib>_static_TARGET variable to the PARENT_SCOPE for each subdirectory in between.

Would be nice to have a consistent solution. Maybe make the install(EXPORT) also available for the local build directory so there's two things generated from the same command (a file in the build directory on compilation and a file in the DESTINATION on install). Or something completely different.
No tags attached.
Issue History
2012-08-06 12:36Michael TänzerNew Issue
2012-08-06 13:01Brad KingNote Added: 0030177
2012-08-07 09:03Michael TänzerNote Added: 0030182
2012-08-07 09:07Brad KingStatusnew => backlog
2015-02-26 03:34Stephen KellyNote Added: 0038075
2015-02-26 03:34Stephen KellyStatusbacklog => resolved
2015-02-26 03:34Stephen KellyFixed in Version => CMake 3.0
2015-02-26 03:34Stephen KellyResolutionopen => fixed
2015-02-26 03:34Stephen KellyAssigned To => Stephen Kelly
2015-07-08 08:57Robert MaynardNote Added: 0039067
2015-07-08 08:57Robert MaynardStatusresolved => closed

Notes
(0030177)
Brad King   
2012-08-06 13:01   
You can use the APPEND mode of export() to incrementally build an exports file. Another approach is to collect a list of targets in a global property and export them all at once at the end.

For example:

  add_library(A ...)
  set_property(GLOBAL APPEND PROPERTY MY_EXPORTED_TARGETS A)
  add_library(B ...)
  set_property(GLOBAL APPEND PROPERTY MY_EXPORTED_TARGETS B)

and at the end of the configuration:

  get_property(_exports GLOBAL PROPERTY MY_EXPORTED_TARGETS)
  export(TARGETS ${_exports} ...)
(0030182)
Michael Tänzer   
2012-08-07 09:03   
Hmm, I still think a uniform mechanism would be good (e.g. a target property containing a list of export configurations it should be deployed in) but for now I'll go with the APPEND mode of export().
(0038075)
Stephen Kelly   
2015-02-26 03:34   
Fixed with

 http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cbe7e8fa [^]
 export: Implement EXPORT subcommand (0009822)
(0039067)
Robert Maynard   
2015-07-08 08:57   
Closing resolved issues that have not been updated in more than 4 months.