Fork me on GitHub


Back to Policies and Guidelines home


generic badge Designates a mandatory point (policy).

generic badge Designates a recommended point (guideline).


Generic badge Version number and build characteristics must be easily accessible

Each product API must include the functionality to return the current version number of the software and indicate which configure/CMake and compiler options were used to build the package. For development versions of the software, a build or install should allow to trace back to the commit ID of the source used.
This allows users to make an inventory of what they have, which is critical for reproducibility, and which can aid debugging and configuration management.
Smart Libraries Practice 10 / xSDK M8

Generic badge Use a limited, unique, and well-defined symbol, macro, library, and include file namespace.

i.e. “Don’t pollute the global namespace”. For example, there should be no publicly visible include files with generic names such as utils.h, a package named libutil.a, or macros named YES or TRUE. Namespacing of include files can be handled either by prepending installed include files with a package name (e.g.,<XXXutils.h>) or by placing and referencing all of them in a subdirectory with the package name (e.g.,<XXX/utils.h>).
Library developers must acknowledge that their software will be built as part of much larger packages. In that context, the use of generic names in the global namespace increases the chance that users of their library will run into build- and link-time errors that must be worked around.
Smart Libraries Practice 18 / Less restrictive than xSDK M9

Generic badge Use MPI in a way that is compatible with other products.