Library Structure - Dividing the library into smaller sublibraries

[rrahn]

Description

The components of the seqan3 library, e.g. the index data structures, the alignment algorithms, the alphabets etc, should be split into their own small libraries, which are then included by seqan3, i.e. it functions as a umbrella library, offering a user friendly "all-fits-one" solution for the app developers over all components. For example, providing a configuration interface for the algorithms while pertaining the general user concepts, e.g. only seqan3::sequence types can be aligned etc. Each sublibrary can be also included into projects individually and should work standalone.

Requirements

• [ ] namespaces: each sublibrary must have a clear unique namespace.

• [ ] library github-template? Just using the application template as a single solution for libraries and apps.

  • problem: app-template includes seqan3 as submodule
  • sublibraries should basically not include seqan3 because seqan3 includes them
  • library-template is fork of app-template
  • how strong should sublibraries be coupled with seqan3?
  • Automation of updates to the template to all registered sublibraries. Can this be automated, how can this be automated?
  • for simplicity we just use the app-template and throw out everything we don't need.
  • mid-term goal: port seqan3-cmake backbone for tests and benchmarks into the app-template, then replace the seqan3 cmake backbone with the one from the app-template (seqan3 derives from the app-template such as any other library).
  • we should test the cyclic dependency if we rely on the seqan3 cmake backbone and seqan3 pulls in the sublibrary which is currently checked-out: e.g. git clone --recursive -> hibf -> seqan3 -> hibf?

• [ ] How should interfaces of low-level sublibraries be exposed within seqan3?

Open/Optional

• [ ] namespaces: like as organisation::project_name, e.g. (seqan::)hibf::; [undecided, branding is nice, but it seems too much for the user. It is not part of the seqan header library]
• [ ] rip out seqan apps and put them into the same app-template framework in order to make them applicable to some workflow systems later. [no priority at the moment, when the respective tool is actually needed]

[smehringer]

Just dumping what I understand are the pro and contra for this

Pro single modules (contra big seqan3 library)

• Separate Versioning (People can work on IO 3.0 while using search 2.0)
• Separate Publishing/Papers
• Inter-module dependencies are avoided (exception: seqan3-base)
• Single modules don't need to have a high code standard right away but can be developed rapidly before being put/released into the umbrella library.
• external dependencies are reduced if apps include modules separately (e.g. no SDSL if I only use alignment)

Contra single modules

• Infrastructure needs to be set up
• Infrastructure needs to be consistent between modules to ensure easy use
• Cross-dependencies might be hard to tackle
• Harder to maintain if code base diverges between code owners