Created Apply the Beman Standard to Beman.Example · Issue #14 · beman-project/exemplar · GitHub to track updates applied to Beman.Example. I have WIP PR for applying existing standard - be ready for review soon.
Do you agree to add an API inside Beman.Example?
I would like to add beman::example::identity(int x)
API to be able to show:
- complete interface example in
include/Beman/Example/example.hpp
. - complete implementation in
src/Beman/Example/example.cpp
. - unit test example, including usage of BUILD_TESTING and conditional pull and build tests and Gtest.
- complete usage example in
examples/sample_usage.cpp
- complete example for CMakeLists.txt files.
- complete README.md example (build, test, run examples).
std::identity might actually be a decent example? Just enough bits to be real, without the complication of being very interesting?
https://en.cppreference.com/w/cpp/utility/functional/identity
I’m generally in favor of making the example project exemplary.
PR ready for review Apply the latest Beman Standard by neatudarius · Pull Request #15 · beman-project/Example · GitHub. std::identity suggestion integrated.
Please check PR descriptions for a complete check list of this PR. Also, there is one which is not specified in the Standard. LIBRARY_NAMES
stats the name of the library (e.g., Beman.Example
or Beman.LongerExample
), but it does not state which is the name of the deliverables - e.g. libexample.a
/ liboptional26.a
/ liblonger_example.a
?
I will add this topic on weekly agenda.
We should make sure that the name used internally matches the name externally. Pkgcfg and CPS both allow for differences between package names and the libraries that are linked, but debugging link problems is easier when there are as few changes as possible.
We should probably add a CI check for the install target and use of it, too. I am pretty sure we’ve broken Optional26, if it ever worked properly. I usually vendor into a super-project rather than use installed versions.