Notes
(0032103) Brad King (manager) 2013-01-15 09:18	The install/export functionality was left out for simplicity because the original implementation was tricky enough as it was. I don't know when upstream devs will have time to work on it as our own motivating use case doesn't need it. Steps to achieve this will include (but probably won't be limited to): (1) Allow "add_library(foo OBJECT IMPORTED)" and define necessary target properties to specify the (per-configuration) object file locations. (2) Teach the export() command to handle object libraries by generating code using the features from step 1. (3) Teach the install(TARGETS) command to handle object libraries somehow. We will need to define what it means to "install" the object files themselves. (4) Teach the install(EXPORT) command to use the features from step 1 and 3.

(0032110) Tomasz Majchrowski (reporter) 2013-01-17 04:45 edited on: 2013-01-17 04:50	Thank you Brad for feedback. What I can describe is the use case that refer to the environment in which I'm working for. Possible you will found it useful for yourself and in general. We have multi-project environment. We would like to completely get rid of creating final library artefacts (static or dynamic) directly from sources. Instead of we would create artefacts always out of the intermediate format/type OBJECT library This will guarantee that in multi-project environments with complex dependency tree, the project which are on the top of dependency tree will be free in creating any kind of artefacts static/dynamic independently from this what is really provided by all depended components. In other words, if we have three independent project which are interact only by export/import interface the following will be possible: Proj_C(binC) --(depends)--> Proj B(libB)--> Proj_C(libC) Now let's assume that Proj_C provides only dynamic version of libC. In the current case it will be not possible to linked binC completely statically without changing CMake build configuration of Proj_C. When support for export/import for intermediate format will be provided, this will become possible. The feature is really important in multi-project environments with complex dependency tree, when project are maintain by different people/teams. The common part is re-use in different context and there is different need to link final artefacts (statically or dynamically) so there is difficult and actually unwanted to control this centrally.

(0042200) Kitware Robot (administrator) 2016-06-10 14:28	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2013-01-15 06:20	Tomasz Majchrowski	New Issue
2013-01-15 09:18	Brad King	Note Added: 0032103
2013-01-15 09:18	Brad King	Severity	minor => feature
2013-01-15 09:18	Brad King	Status	new => backlog
2013-01-17 04:45	Tomasz Majchrowski	Note Added: 0032110
2013-01-17 04:46	Tomasz Majchrowski	Note Edited: 0032110
2013-01-17 04:46	Tomasz Majchrowski	Note Edited: 0032110
2013-01-17 04:46	Tomasz Majchrowski	Note Edited: 0032110
2013-01-17 04:47	Tomasz Majchrowski	Note Edited: 0032110
2013-01-17 04:47	Tomasz Majchrowski	Note Edited: 0032110
2013-01-17 04:50	Tomasz Majchrowski	Note Edited: 0032110
2016-06-10 14:28	Kitware Robot	Note Added: 0042200
2016-06-10 14:28	Kitware Robot	Status	backlog => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:28	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships