Feature #12995
Question on split canvas libraries
Description
Canvas builds four libraries:
- canvas_Version
- canvas_Utilities
- canvas_Persistency_Common
- canvas_Persistency_Provenance
plus the dictionary components. Whilst I recognise development of canvas/gallery/art is in flux, I wanted to ask about the technical requirements leading to having four libraries here. Upstream uses of canvas appear to link to most of it anyway (gallery, most bits of art), so with canvas being pretty lightweight, this split feels/looks on the surface like it leads to more complexity for clients (I use headers from canvas, but which libs do I need to link to?).
Modularisation is good for large projects, but with the seeming simplicity of canvas, would a library structure
- canvas
- canvas_{dict,map}.{so,pcm,etc}
- dicts for third-party libs
be possible, or rather, are their technical reasons to disfavour this organisation? For example, it would appear to make building anything that uses canvas easier, e.g. in gallery, one would replace (using pure CMake, and assuming namespaced exported targets as per CMake recommendations):
add_library(gallery SHARED ${gallery_SOURCES}) target_link_libraries(gallery PUBLIC canvas::canvas_Persistency_Common canvas::canvas_Persistency_Provenance canvas::canvas_Utilities )
with
add_library(gallery SHARED ${gallery_SOURCES}) target_link_libraries(gallery PUBLIC canvas::canvas)
If there are costs to the single lib structure then the more complex structure is handled, but it seems a good idea to simplify if possible.
History
#1 Updated by Kyle Knoepfel over 4 years ago
- Status changed from New to Feedback
The set of libraries built were meant to make the experiment transition as easy as possible when migrating from art
to art
-plus-canvas
. There are also various libraries within art
that do not need to link against the entire canvas
library set.
If the stakeholders would welcome the simplification of merging everything into one library, then we will do it.
#2 Updated by Kyle Knoepfel over 4 years ago
The response from the stakeholders was inconclusive. However, we support this proposal. Since such a change will require adaptation of build scripts for all of the experiments, we will notify them of the proposal. Assuming no objections, we will go ahead and combine everything into one canvas
library.
#3 Updated by Kyle Knoepfel about 4 years ago
- Tracker changed from Support to Feature
- Status changed from Feedback to Accepted
There have been no objections voiced from the stakeholders. We will proceed with this proposal.
#4 Updated by Christopher Green about 4 years ago
- Status changed from Accepted to Resolved
- Assignee set to Christopher Green
- Target version set to 2.06.00
- % Done changed from 0 to 100
- SSI Package - added
Resolved with commits canvas:b8b7a4b, art:f7d4c745, gallery:cd098cb and critic:24a772e.
#5 Updated by Kyle Knoepfel about 4 years ago
- Status changed from Resolved to Closed