More SW infrastructure #9
Conversation
Adopting a MAJOR.MINOR.PATCH/REVISION version numbering scheme for the OpenTurbine codebase. This will enable us to report the build version in log files among other things.
Added Doxyfile and mainpage.txt files to create API documentation for the project.
- The version info was added to CMake output as part of Pull Request Exawind#11, which made adding a separate version # information into the CMakeLists project() redundant.
- Adopted the Google C++ Style Guide for OpenTurbine project along with several modifications - Ran the clang-format linter on the repo *.h and *.cpp files
- Build on the google C++ style guide to customize it for OpenTurbine - Add comments to explain the specific departures from google style
- Log class added to support logging feature to console and/or to file - Based on a Singleton design
…main CMakeLists file - Defs of the build type added to customize the compilation e.g. to set log severity level
- Look for build type in the list of supported types - If none is provided or type does not match then set to RELEASE - print the build type in a status message
- Move io related code to src/io/ - Move heat_solve related code to src/heat/ - Make necessary changes to CMakeList files to accomodate above
- Change namespace for debug_utils from openturbine::debug -> openturbine::util - pass argument to print_vector by const &
- Two methods removed from logging capabilities since they were not used - Changed deleted destructor and move ctors to default - Modified the doxygen comments in log.h file to add more clarity - changed namespace to openturbine::util
- source code folder structure - namespace changes
|
Updates to the PR:
In addition to the above, a slight adjustment was made to the folder structure within |
…cause it's not a valid build type in CMake
…nment to logging objectives
faisal-bhuiyan
added
cmake
Following enhancements to the OpenTurbine SW infrastructure are proposed here:
Create API documentation via Doxygen - Use of doxygen specific annotation embedded within C++ source code is pretty common to generate API documentation with minimal effort, e.g. in AMR wind.
Adopt a version number for project in CMakeLists.txt - we might consider adopting a version number for OpenTurbine using CMake. We could use the version number along with a log file (discussed below) to quickly check the build version for development as well as for releases.
Create a logging utility - a logging utility for recording log messages to files (alongside the console) should be a very useful development tool and the first point of debugging whenever necessary. Various open-source libraries are available for this such as spdlog, however, we could just implement our own basic logging utility with minimal effort.
Adopt a C++ Style guide - We are currently using the C++ style guide in the form of a
clang-formatas recommended in amr-wind. However, having a descriptive style guide helps to know about the thought process behind the choices made. The Google C++ style guide might be a good candidate to this end, of course with a few modifications of our own, e.g., increasing the line length from 80 characters to a more reasonable value such as 120.