Project

General

Profile

Feature #12995

Question on split canvas libraries

Added by Ben Morgan about 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
06/22/2016
Due date:
% Done:

100%

Estimated time:
Spent time:
Scope:
Internal
Experiment:
DUNE
SSI Package:
-
Duration:

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 about 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 3 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 over 3 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 over 3 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

#5 Updated by Kyle Knoepfel over 3 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF