support more flexible installation paths for modules or user code
When compiling additional modules or user code, we need more flexibility for the installation locations. We currently have three possible locations:
- user locations - eg,
- group locations - eg
- project locations - eg,
The difficulty is that project or site directories could be read-only, or the person compiling things might want to create a package for a group of users and it is difficult to fish these back out of their user directory.
Developer or packager wishing to harness OpenFOAM and possibly combine with some arbitrary other software. For example, if we wish to compile a module using an installed OpenFOAM code base but using some particular petsc, paraview, vtk version. We would like to work with pristine sources, but compile/recompile the interfaces as required and make them available as additional layers or system modules.
To address this, it is proposed to introduce three additional make variables for the purposes of compilation:
- FOAM_MODULE_PREFIX - default is unset
- FOAM_MODULE_APPBIN - if unset and FOAM_MODULE_PREFIX is set, treat as
- FOAM_MODULE_LIBBIN - if unset and FOAM_MODULE_PREFIX is set, treat as
Contain the logic in the
- module-path-prefix : the logic described above
- module-path-user : use FOAM_USER_APPBIN, FOAM_USER_LIBBIN for the defaults
- module-path-group : use FOAM_SITE_APPBIN, FOAM_SITE_LIBBIN for the defaults
- module-path-project : use FOAM_APPBIN, FOAM_LIBBIN for the defaults
For the developer
The above logic is indeed ugly, but should be clean enough to use for the developer.
It will require changes in the
For the packager
If the above changes are implemented, it is then possible for the person compiling/packaging to specify different install locations. For example,
FOAM_MODULE_LIBBIN=$HOME/tmp-prefix/lib wmake libso
Some work has already been done (see commit aafe674f) to handle a
-prefix argument to define
CMAKE_INSTALL_PREFIX. Could simply extend that to set
FOAM_MODULE_PREFIX as well.
Another possibility is would be to support
wmake -module-prefix=... directly, which would free us from dependence on an
Using these mechanisms with an arbitrary prefix may require temporary addition of the bin directory to the PATH, if the module or utility is compiling tools for itself. Can probably address this on an individual basis.