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:

/opt/ohpc

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:

%global PROJ_NAME       ohpc
%global OHPC_HOME       /opt/%{PROJ_NAME}
%global OHPC_ADMIN      %{OHPC_HOME}/admin
%global OHPC_PUB        %{OHPC_HOME}/pub
%global OHPC_APPS       %{OHPC_PUB}/apps
%global OHPC_COMPILERS  %{OHPC_PUB}/compiler
%global OHPC_LIBS       %{OHPC_PUB}/libs
%global OHPC_MODULES    %{OHPC_PUB}/modulefiles
%global OHPC_MODULEDEPS %{OHPC_PUB}/moduledeps
%global OHPC_MPI_STACKS %{OHPC_PUB}/mpi
%global OHPC_UTILS      %{OHPC_PUB}/utils

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

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
EOF

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.