Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delivery as stand-alone library / SDK #34

Open
jenszo opened this issue Feb 5, 2021 · 1 comment
Open

Delivery as stand-alone library / SDK #34

jenszo opened this issue Feb 5, 2021 · 1 comment

Comments

@jenszo
Copy link
Contributor

jenszo commented Feb 5, 2021

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?

@btaczala
Copy link
Collaborator

btaczala commented Apr 9, 2021

Hi, sorry for late response.
We're interested in other use cases (other than our own) and we would love to take some of the changes from your fork and merge it.

On points you've raised:

  • fPIC is more than ok. Generally we should follows CMake's BUILD_SHARED_LIBS if it is set than we should produce a shared library if not a static one. One thing might be trying to keep some ABI compability, but who cares about ABI nowadays right? :)
  • Third party subdir always bothered me to some extend as there are some other "meta" build system I'm planning to use CANdb with (yocto, conan). We should have a way of pulling the deps if needed (via submodules) or providing them via system package managers (or other means)
  • I'm all for *.cmake files to make it easier to find CANdb especially that this should be a base for other projects

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants