Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • openfoam openfoam
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 380
    • Issues 380
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 11
    • Merge requests 11
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • openfoamopenfoam
  • Issues
  • #1721

Closed
Open
Created Jun 05, 2020 by Mark Olesen@markMaintainer

support more flexible installation paths for modules or user code

The problem

When compiling additional modules or user code, we need more flexibility for the installation locations. We currently have three possible locations:

  1. user locations - eg, $FOAM_USER_LIBBIN
  2. group locations - eg $FOAM_SITE_LIBBIN
  3. project locations - eg, $FOAM_LIBBIN

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.

Target audience

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.

Possible solution

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_PREFIX)/bin
  • FOAM_MODULE_LIBBIN - if unset and FOAM_MODULE_PREFIX is set, treat as $(FOAM_MODULE_PREFIX)/lib

Contain the logic in the wmake/rules/General rules

  • 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 Make/options and Make/files files.

before

default location Make/options Make/files
user LIB = $(FOAM_USER_LIBBIN)/libXYZ
group LIB = $(FOAM_SITE_LIBBIN)/libXYZ
project (OpenFOAM) LIB = $(FOAM_LIBBIN)/libXYZ

after

default location Make/options Make/files
user include $(GENERAL_RULES)/module-path-user LIB = $(FOAM_MODULE_LIBBIN)/libXYZ
group include $(GENERAL_RULES)/module-path-group LIB = $(FOAM_MODULE_LIBBIN)/libXYZ
project (OpenFOAM) include $(GENERAL_RULES)/module-path-project LIB = $(FOAM_MODULE_LIBBIN)/libXYZ

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_PREFIX=/path/my-install-location  ./Allwmake

or

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 Allwmake script.

Open points

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.

Edited Jun 08, 2020 by Mark Olesen
Assignee
Assign to
Time tracking