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?
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?