You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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
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
This all should not undervalue your work - and I love the way this parser is implemented.
Any thoughts on this?
The text was updated successfully, but these errors were encountered: