- allows reuse of an int64_t scotch library with label-size 32
and/or label-size 64.
COMP: prefer scotch/metis/kahip libraries with label-size qualifiers
- as noted in #2200, mpirun may insert mpi libraries higher in the
library loader which can cause masking of our ThirdParty libraries
of the same name. With scotch (for example), the operating system
may have an int32 version installed but we have an int64 version
compiled under ThirdParty. Runing in serial is fine, but in parallel
we resolve to the (incorrect) system version due to the adjustments
in mpirun.
- adjust the ThirdParty make scripts to also create corresponding
links (eg, 'ln -s libscotch.so libscotch-int64.so') and prefer
linkage with these qualified libraries.
Eg, -L$(SCOTCH_LIB_DIR) -lscotch$(SCOTCH_LIBNAME_SUFFIX)
this prevent accidental runtime linkage with the system versions.
STYLE: simplify scotch interface code by using local functions
- add to wmakeFunctions to ensure it works even without 'make' being
installed. Exit immediately after -show-api for consistency with
-version.
foamEtcFile:
- drop warnings for some old (pre-v1812) defunct options
and simply flag as unknown options.
- handle -version, --version as equivalent to -show-api
- largely as per patch from Jong-Gwan (Jason) Do
NB: the intel-one setup adds in paths for intelmpi.
Its mpicc version does not harmonize with the OpenFOAM
system openmpi setup (using mpicc --showme:link).
Needs adjustment, or use intelmpi instead.
- update name mappings for newer gcc, clang versions
- previously had a very old (likely irrelevant) setting for solaris
systems only.
- support site-specific customization.
Eg, using etc/config.{csh,sh}/prefs.fjmpi
- remove erroneous shell redirects present in cshell files
- since the wrapped cmake calls generally use the regular build
locations, add in MPI information to properly handle changes
in that as well. This makes it easier to build for multiple MPI
instances.
Example usage,
wmake -with-bear src/OpenFOAM
src/Allwmake -with-bear -s -j
- bin/tools/vscode-settings
Emit some json content suitable for setting up Visual Studio Code
for use with OpenFOAM.
For example,
bin/tools/vscode-settings > .vscode/settings.json
Ideas from Volker Weissman
- prefix FOAM_MPI and library directories with 'sys-' for system
versions for uniform identication.
WM_MPLIB | libdir (FOAM_MPI) | old naming |
SYSTEMMPI | sys-mpi | mpi |
SYSTEMOPENMPI | sys-openmpi | openmpi-system |
- prefix preferences with 'prefs.' to make them more easily
identifiable, and update bin/tools/create-mpi-config accordingly
Old name: config.{csh,sh}/openmpi
New name: config.{csh,sh}/prefs.openmpi
- additional mpi preferences now available:
* prefs.intelmpi
* prefs.mpich
...
CONFIG: added hook for EASYBUILDMPI (eb-mpi), somewhat like USERMPI
- EasyBuild uses mpicc when compiling, so no explicit wmake rules are
used
ENH: support different major versions for system openmpi
- for example, with
WM_MPLIB=SYSTEMOPENMPI2
defines FOAM_MPI=sys-openmpi2 and thus creates lib/sys-openmpi2
ENH: centralize handling of mpi as 'mpi-rules'
Before:
sinclude $(GENERAL_RULES)/mplib$(WM_MPLIB)
sinclude $(DEFAULT_RULES)/mplib$(WM_MPLIB)
ifeq (,$(FOAM_MPI_LIBBIN))
FOAM_MPI_LIBBIN := $(FOAM_LIBBIN)/$(FOAM_MPI)
endif
After:
include $(GENERAL_RULES)/mpi-rules
- also allows variants such as SYSTEMOPENMPI2 to be handled separately
ENH: provide fallback prefix for cmake detection
STYLE: simplify some shell syntax, avoid uname call in sysFunctions
STYLE: report FOAM_MPI during mpiLib builds
- no limit to the number of ways of filing ptscotch libraries.
RedHat/Fedora/CentOS should look for these directories:
ptscotch include=/usr/include/openmpi-x86_64
ptscotch library=/usr/lib64/openmpi/lib
when MPI_ARCH_PATH=/usr/lib64/openmpi
and mpicc --showme:compile yields -I/usr/include/openmpi-x86_64
- ensures that subsequent Allwmake scripts know about it.
ENH: add bin/tools/query-detect wrapper for wmake have_* scripts
CONFIG: use project/ThirdParty without additional sanity checks
- no need to test for Allwmake or platforms/ if ThirdParty is located
within the project directory itself.
COMP: add simple mpi test to 00-dummy
- for testing library linkage, etc.
- on ArchLinux, everything is installed under /usr/include/scotch.
The detection script uses SCOTCH_ARCH_PATH as an initial guess for
ptscotch as well. However, on the second pass, it has an absolute
value ("/usr") instead of a logical one ("scotch-system").
This resulted in the logic for handling scotch+ptscotch subdirs
being bypassed.
- introduce WM_COMPILE_CONTROL variable to convey control information
into the build rules.
The convention (as per spack):
- '+' to select a feature
- '~' to deselect a feature
Eg, to select the gold linker, and disable openmp
(spaces are not required):
WM_COMPILE_CONTROL="+gold ~openmp"
CONFIG: accept FOAM_EXTRA_LDFLAGS for AMD, gold, Mingw linkers
CONFIG: generalize PROJECT_LIBS (-ldl used almost universally)
- experienced while reusing src/Pstream/Allwmake-mpi to create
additional mpi-layers after installation. Since the copied sources
are not located within the OpenFOAM source-tree (and/or the
source-tree is non-writable), it should not and does not use the
central build/WM_OPTIONS directory.
However, when exploring for the appropriate local Make directory, it
searched for the current '.' directory instead of checking for the
resolved directory.
This fails, since there is no src/Pstream/Make directory.
Must check for src/Pstream/mpi/Make directory first!
- Adjust wclean to always remove a local build directory
(Make/WM_OPTIONS) for additional safety.
After which, attempt to remove central build/WM_OPTIONS version too.
- previously hidden as Detail::[IO]FstreamAllocator, now exposed
directly as [io]fstreamPointer, which allows reuse for
std::ifstream, std::ofstream wrapping, without the additional
ISstream, OSstream layers.
These stream pointers have some characteristics similar to a
unique_ptr.
- restrict direct gzstream usage to two files (fstreamPointers.C,
gzstream.C) which improves localization and makes it simpler to
enable/disable with the `HAVE_LIBZ` define.
The HAVE_LIBZ define is currently simply hard-coded in the
Make/options.
If compiled WITHOUT libz support:
- reading gz files : FatalError
- writing gz files : emit warning and downgrade to uncompressed
- warn if compression is specified in the case controlDict
and downgrade to uncompressed
ENH: minor updates to gzstream interface for C++11
- support construct/open with std::string for the file names.
CONFIG: provisioning for have_libz detection as wmake/script
- the various information queries MUST be executed with
the '--no-print-directory' or risk polluting values
in the information queries.
This is mostly seen with the 'canCompile' test for tutorials running
in parallel.
- the various information queries MUST be executed with
the '--no-print-directory' or risk polluting values
in the information queries.
This is mostly seen with the 'canCompile' test for tutorials running
in parallel.
- replace `%namespace` directive with simpler `%static` directive.
We always encapsulate Lemon parser routines in an anonymous
namespace, so a simpler static linkage directive suffices.
This reduces the size of the Lemon patch (program and template).
- When OpenFOAM is under git control and a 'debian/' directory exists,
this could mean two things:
1) Additional debian control has been added to OpenFOAM
2) OpenFOAM has been imported into a debian project
For the case that OpenFOAM has been imported into a debian project,
using the git information would be highly misleading. There will be no
OpenFOAM SHA1 correspondence.
However, if additional debian control has been added to OpenFOAM the
SHA1 will be valid.
The ad hoc solution is to use an additional "openfoam.debian"
directory to flag the addition of debian controls into openfoam.
When a "debian/" directory exists without a "openfoam.debian", assume
that the OpenFOAM has been imported into debian and do not use the SHA1.
- when installed in-source, use PETSC_ARCH to find additional include
directory and the correct library directory
CONFIG: bump to new hypre version
- add -hint option for have_adios2, have_hypre, have_petsc
- When compiling additional modules or user code, we need more control
for the installation locations beyond the usual FOAM_USER_LIBBIN,
FOAM_SITE_LIBBIN, FOAM_LIBBIN, and wish to have these values be
modifiable without editing files.
- provide wmake rules for handling standard defaults:
* GENERAL_RULES/module-path-user
* GENERAL_RULES/module-path-group
* GENERAL_RULES/module-path-project
which are incorporated as follows:
Make/options:
include $(GENERAL_RULES)/module-path-user
Make/files:
LIB = $(FOAM_MODULE_LIBBIN)/libMyLibrary
By default these would compile into FOAM_USER_{APPBIN,LIBBIN} but
could be adjusted at compilation time. For example,
```
wmake -module-prefix=/path/my-install-location
```
Or
```
./Allwmake -module-prefix=/path/my-install-location
./Allwmake -prefix=/path/my-install-location
```
Or
```
FOAM_MODULE_PREFIX=/path/my-install-location ./Allwmake
```
ENH: add -no-recursion option for AllwmakeParseArguments
- more descriptive naming than the -fromWmake option (still supported)
- remove wmake/scripts/wmake.{cmake,wmake}-args since the -prefix
handling and -no-recursion is now directly handled by AllwmakeParseArguments
