Packaging

Back to Policies and Guidelines home


Legend

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

Details
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.
Rationale
This allows users to make an inventory of what they have, which is critical for reproducibility, and which can aid debugging and configuration management.
Ref
Smart Libraries Practice 10 / xSDK M8

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

Details
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>).
Rationale
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.
Ref
Smart Libraries Practice 18 / Less restrictive than xSDK M9

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

Details:

Ref
xSDK M3