MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013848CMakeCMakepublic2013-01-15 06:202016-06-10 14:31
ReporterTomasz Majchrowski 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionmoved 
PlatformLinuxOSRHELOS Version6.3
Product VersionCMake 2.8.10.2 
Target VersionFixed in Version 
Summary0013848: Object_Library limitation import/export
DescriptionWe found newly introduce "OBJECT" library type very useful. In
particular we found use case in the context of re-usage the same
object to provide static and dynamic version of the library.

Unfortunately in the current version there is no possibility to
IMPORT/EXPORT this library type. This limitation actually eliminate
usage of this feature in the multi-project environments.

Therefore we would like to kindly request this functionality
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-01-15 06:20Tomasz MajchrowskiNew Issue
2013-01-15 09:18Brad KingNote Added: 0032103
2013-01-15 09:18Brad KingSeverityminor => feature
2013-01-15 09:18Brad KingStatusnew => backlog
2013-01-17 04:45Tomasz MajchrowskiNote Added: 0032110
2013-01-17 04:46Tomasz MajchrowskiNote Edited: 0032110bug_revision_view_page.php?bugnote_id=32110#r999
2013-01-17 04:46Tomasz MajchrowskiNote Edited: 0032110bug_revision_view_page.php?bugnote_id=32110#r1000
2013-01-17 04:46Tomasz MajchrowskiNote Edited: 0032110bug_revision_view_page.php?bugnote_id=32110#r1001
2013-01-17 04:47Tomasz MajchrowskiNote Edited: 0032110bug_revision_view_page.php?bugnote_id=32110#r1002
2013-01-17 04:47Tomasz MajchrowskiNote Edited: 0032110bug_revision_view_page.php?bugnote_id=32110#r1003
2013-01-17 04:50Tomasz MajchrowskiNote Edited: 0032110bug_revision_view_page.php?bugnote_id=32110#r1004
2016-06-10 14:28Kitware RobotNote Added: 0042200
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0032103)
Brad King   
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   
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   
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.