- tie the MPI rules to the base compiler type *without* its version.
  Eg, linux64Gcc (which exists) instead of linux64Gcc81

- initial settings for ADIOS2, linuxARM64Gcc, linuxARM64Clang

- the cray C/C++ compilers appear to be option-compatible with gcc.

- no wmake rules for 32bit builds (deemed to be unnecessary)

- not yet release, but some of the API and file locations are closer
  to 1706 than to 1612. Needed, for example, for swak4foam.

- minor cleanup of wmake sources

- use "-pvMAJ.MIN" suffix for similarity with the paraview convention

- use sentinel file to ensure clean change of intermediate targets

- ensure all library files are being properly removed

- slightly odd. Building CGAL on other Linux systems have a proper
  ldd dependency for gmp/mpfr, but ubuntu doesn't

- now that adios_config flags are largely working in ThirdParty

- support gperftools-none, gperftools-system configurations
  as per other third-party packages.

STYLE: clean up more environment variables

CONFIG: testing adios rule

- these directories are sometimes used for a central, non-thirdparty, non-system
  installation

- leave gmp and mpfr as is, since it is not clear how these would interact with system
  versions

Based on patch contributed by Alexey Matveichev
Resolves feature request http://bugs.openfoam.org/view.php?id=2328

On 64-bit systems, the system installations of boost, cgal are under
lib64/. The behaviour for a ThirdParty build is mostly lib/ but this
can also be changing.

    Boost 1_62_0 and older build into 'lib/'.
    CGAL-4.9 builds into 'lib64/', older versions into 'lib/'.

Future-proof things by using lib$WM_COMPILER_LIB_ARCH for boost and
cgal build rules, and forcing these as build targets in the ThirdParty
makeCGAL as well.

--
STYLE: check for boost/version.hpp, CGAL/version.h instead their directories

Resolves bug-report http://bugs.openfoam.org/view.php?id=2283

- CGAL itself includes its library dependencies, we only need to
  provide the -L... option to the proper ThirdParty locations.

  Should help improve general build robustness.

- 64-bit builds of gcc/mpfr/gmp use lib64/ for their installation path.
  Use this for the wmake rules as well.

The pre-processor macro 'OPENFOAM_PLUS' is defined with a numerical
value equal to the currently compatible version number.

This can be used judiciously within user coding to help with minor
differences between OpenFOAM versions. For example,

    #ifdef OPENFOAM_PLUS
        #if (OPENFOAM_PLUS >= 1612)
        ...
        #endif
    #endif

or simply

    #if (OPENFOAM_PLUS >= 1612)
    ...
    #endif

Patch contributed by Bruno Santos
Resolves patch request http://bugs.openfoam.org/view.php?id=2114

which may be optionally overridden by version-specific rules.

For example the default rules for gcc on GNU/Linux x86_64 are in the
wmake/rules/linux64Gcc directory.  If there is a need to change any of
the rules for a specific version of gcc, e.g. gcc-4.8.4 the directory
wmake/rules/linux64Gcc48 may be created into which any of the language
files may be provided containing the rules to override the defaults.

On 32bit OSs long is not unambiguously int32_t (or int64_t) causing
problems for IO operator resolution.  This problem is avoided by
explicitly defining the following operators:

Provided by Bruno Santos
Also some general cleaning and update of comment.
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1167

Tested with snapshot gcc-5-20150215.tar.bz2

To compile with 64bit labels set

WM_LABEL_SIZE=64

in ~/OpenFOAM/dev/prefs.sh

source ~/.bashrc

then Allwmake in OpenFOAM-dev.

This will build into for example OpenFOAM-dev/platforms/linux64ClangDPInt64Opt

If WM_LABEL_SIZE is unset or set to 32:

WM_LABEL_SIZE=32

the build would be placed into OpenFOAM-dev/platforms/linux64ClangDPInt32Opt

Thus both 32bit and 64bit label builds can coexist without problem.

This is so that surfaceFeatureExtract will compile without boost/mpfr