Path Conventions

When practical, OpenHPC packaging endeavors to install into a consistent directory organization (although some packages that are not easily amenable to non-default path installations do not follow this strategy).  The typical top-level organizing installation path is:


A variety of pre-defined RPM macro definitions are used to organize installations underneath this top-level path. These definitions are housed in the components/OHPC_macros file and a subset of this file is shown here to illustrate common macro names available for use by packagers:

%define PROJ_NAME ohpc
%define OHPC_HOME /opt/%{PROJ_NAME}
%define OHPC_ADMIN %{OHPC_HOME}/admin
%define OHPC_PUB %{OHPC_HOME}/pub
%define OHPC_COMPILERS %{OHPC_PUB}/compiler
%define OHPC_APPS %{OHPC_PUB}/apps
%define OHPC_LIBS %{OHPC_PUB}/libs
%define OHPC_MODULES %{OHPC_PUB}/modulefiles
%define OHPC_MODULEDEPS %{OHPC_PUB}/moduledeps

Note that the naming scheme is organized around functionality with separate macros defined for compilers, mpi toolchains, 3rd party libraries, and modulefiles.

Naming Conventions

In addition to a set of path conventions, the RPM naming for scheme OpenHPC packages also strives for consistency. To avoid potential conflicts with other packaging repositories, OpenHPC packages are appended with a common delimiter of “-ohpc“.  Also, since OpenHPC supports a variety of compiler and MPI toolchains, multiple builds for the same component package are necessary and are reflected in the RPM naming scheme.

The general naming convention  is to append the compiler and MPI family name that the library was built against directly into the package name. For example, libraries that do not require MPI as part of the build process adopt the following RPM name:

package-<compiler family>-ohpc-<package version>-<release>.rpm

Packages that require MPI as part of the build expand upon this convention to additionally include the MPI family name as follows:

package-<compiler family>-<mpi family>-ohpc-<package version>-<release>.rpm


Module Conventions

In order to provide a flexible development environment, OpenHPC adopts the use of modules (via Lmod) and includes creation of module files for relevant components as part of the build process. If you are not familiar with modules, they provide a convenient way to setup standard environment variables (e.g. PATH, LD_LIBRARY_PATH, etc) in your shell in order to access and compile against provided software components.  Furthermore, OpenHPC leverages the hierarchical capability of Lmod to ensure a consistent development environment is maintained.  In addition to setting common environment variables like PATH and LD_LIBRARY_PATH, the packaging conventions also define a set of component-specific environment variables that provide convenience mapping to the top-level install path and location of component binaries, development (header) files, libraries, and documentation.   To illustrate this convention and resulting environment variable names, the following highlights the relevant modulefile commands included in the .spec file for the Adios package.

%{__mkdir} -p %{buildroot}%{OHPC_MODULEDEPS}/%{compiler_family}-%{mpi_family}/%{pname}
%{__cat} << EOF > %{buildroot}/%{OHPC_MODULEDEPS}/%{compiler_family}-%{mpi_family}/%{pname}/%{version}
setenv          ADIOS_DIR        %{install_path}
setenv          ADIOS_DOC        %{install_path}/docs
setenv          ADIOS_BIN        %{install_path}/bin
setenv          ADIOS_LIB        %{install_path}/lib
setenv          ADIOS_INC        %{install_path}/include

Note that the %{} macro variables referenced in the above would have all been been defined previously in the .spec file. See the Build Environment discussion for more information regarding the %{compiler_family} and %{mpi_family} definitions.