cet-is » canvas

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.