Skip to content

Delivery as stand-alone library / SDK #34

@jenszo

Description

@jenszo

I am using CANdb in multiple small projects by now, usually linked statically (to executables and shared plugins) to reduce build times and to guarantee build stability/ code compatibility over time. By now, I am maintaining my own fork which I adapt for my specific needs to accommodate for this. I understand you are pursuing a more "rolling" release of your software collection. However, I was wondering if you were interested in any of the following from here: https://github.com/jenszo/CANdb/tree/simple_library_api

  • "DBCSimpleParser" - my wrapper with d-pointer to hide std::expected from linking target and reducing potential binary conflicts in case std::expected changes and/or user code ships it's own variant (CanDbOrError is part of your API).
  • -fPIC compilation to allow static linkage to shared plugins in the first place
  • Pinning specific versions of the dependencies (cxxopts, spdlog, etc.) Particularly spdlog is critical as the current implementation requires user-code to implement a kDefaultLogger (which is marked extern in the static library) and this may again lead to a broken ABI.
  • shipping a *.cmake file for CANdb for cmake to be able to search for it and import a library target.

This all should not undervalue your work - and I love the way this parser is implemented.
Any thoughts on this?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions