- drop FOAM_MPI_LIBBIN variable in favour of FOAM_MPI from which
two different locations can be determined.
Previously there was something like this:
FOAM_MPI_LIBBIN = $FOAM_LIBBIN/openmpi-1.5.1
We now instead determine the locations from the FOAM_MPI directly:
FOAM_MPI=openmpi-1.5.1
$FOAM_LIBBIN/$FOAM_MPI -> OpenFOAM mpi-related
$FOAM_EXT_LIBBIN/$FOAM_MPI -> ThirdPary mpi-related
ENH: relocate ParaView libraries and plugins back under FOAM_LIBBIN
- as discussed with Mattijs
non-numeric (eg, a git or cvs version).
- place the onus on the user to provide the correct ParaView_MAJOR in
these situations.
STYLE: Drop support for cmake older than 2.6.4 (installed in 3rdParty)
old: $WM_THIRD_PARTY_DIR/<packageName>/platforms/$WM_ARCH*
new: $WM_THIRD_PARTY_DIR/platforms/$WM_ARCH*/<packageName>
This streamlines the creation of binary packs, eases distribution and
helps when testing the robustness of relocatable installations.
leading text
* Something like ParaView_MAJOR=ParaView_3.6 would have previously
been possible, but this violates paraview's expectation of having
"lib/paraview-<digits>.<digits>"
* TODO? If desired, the ParaView_MAJOR could be determined
automatically in the script.
For example,
ParaView_MAJOR=`echo $ParaView_VERSION | \
sed -e 's/^\([0-9][0-9]*\.[0-9][0-9]*\).*$/\1/'`
Or even,
ParaView_MAJOR=${ParaView_VERSION%.[0-9]}
Except that the second version fails if the minor version reaches
double digits.
- moved to $FOAM_LIBBIN/paraview so that built libraries sit in their
own folder - avoids PV error msgs on start-up when it tries to load
all libs under the $PV_PLUGIN_PATH
- get version from $ParaView_VERSION or from -version option
- added QT gui support (useful when compiling enGrid)
- update files for finding cmake-2.6.4 as well
- added bin/engridFoam for calling a version of enGrid that uses the
paraview libraries compiled with/for OpenFOAM
- added foam3rdParty change directory alias
- The new cmake seems to be even smarter. If we try to use env variables in
the .cmake files (eg, with And's sed fixup), they are rewritten in a
subsequent re-make and take much longer). Adjusting the compiler values
themselves causes a full remake. On the positive side, disabling the rpath
seems to mean we may not need any of this.
In summary - yuck!