- now only needed when specify compiling -m32 on a 64-bit system.

  Internally use the __SIZEOF_LONG__ compiler macro (gcc, icc, llvm)
  to define when long is actually an int32_t.

- adjust copyright dates for manpages

- replace (darwin) with (__APPLE__)
- replace (solarisGcc) with (__sun__ && __GNUC__)
- instead of 'darwin' -> '__APPLE'

- cease with passing a -D$(WM_ARCH) define since this adds no useful
  additional information and isn't used anywhere.

Reference
http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system

--

COMP: Extend size disambiguation on long (#1238)

- relocates some logic from makefiles/general into platform-specific
  overrides

  - objectRegistry search, erase methods
  - clip, minMax
  - function object triggering
  ...

STYLE: generalize rule for obtaining compiler stem

Previously the coordinate system functionality was split between
coordinateSystem and coordinateRotation. The coordinateRotation stored
the rotation tensor and handled all tensor transformations.

The functionality has now been revised and consolidated into the
coordinateSystem classes. The sole purpose of coordinateRotation
is now just to provide a selectable mechanism of how to define the
rotation tensor (eg, axis-angle, euler angles, local axes) for user
input, but after providing the appropriate rotation tensor it has
no further influence on the transformations.

--

The coordinateSystem class now contains an origin and a base rotation
tensor directly and various transformation methods.

  - The origin represents the "shift" for a local coordinate system.

  - The base rotation tensor represents the "tilt" or orientation
    of the local coordinate system in general (eg, for mapping
    positions), but may require position-dependent tensors when
    transforming vectors and tensors.

For some coordinate systems (currently the cylindrical coordinate system),
the rotation tensor required for rotating a vector or tensor is
position-dependent.

The new coordinateSystem and its derivates (cartesian, cylindrical,
indirect) now provide a uniform() method to define if the rotation
tensor is position dependent/independent.

The coordinateSystem transform and invTransform methods are now
available in two-parameter forms for obtaining position-dependent
rotation tensors. Eg,

      ... = cs.transform(globalPt, someVector);

In some cases it can be useful to use query uniform() to avoid
storage of redundant values.

      if (cs.uniform())
      {
          vector xx = cs.transform(someVector);
      }
      else
      {
          List<vector> xx = cs.transform(manyPoints, someVector);
      }

Support transform/invTransform for common data types:
   (scalar, vector, sphericalTensor, symmTensor, tensor).

====================
  Breaking Changes
====================

- These changes to coordinate systems and rotations may represent
  a breaking change for existing user coding.

- Relocating the rotation tensor into coordinateSystem itself means
  that the coordinate system 'R()' method now returns the rotation
  directly instead of the coordinateRotation. The method name 'R()'
  was chosen for consistency with other low-level entities (eg,
  quaternion).

  The following changes will be needed in coding:

      Old:  tensor rot = cs.R().R();
      New:  tensor rot = cs.R();

      Old:  cs.R().transform(...);
      New:  cs.transform(...);

  Accessing the runTime selectable coordinateRotation
  has moved to the rotation() method:

      Old:  Info<< "Rotation input: " << cs.R() << nl;
      New:  Info<< "Rotation input: " << cs.rotation() << nl;

- Naming consistency changes may also cause code to break.

      Old:  transformVector()
      New:  transformPrincipal()

  The old method name transformTensor() now simply becomes transform().

====================
  New methods
====================

For operations requiring caching of the coordinate rotations, the
'R()' method can be used with multiple input points:

       tensorField rots(cs.R(somePoints));

   and later

       Foam::transformList(rots, someVectors);

The rotation() method can also be used to change the rotation tensor
via a new coordinateRotation definition (issue #879).

The new methods transformPoint/invTransformPoint provide
transformations with an origin offset using Cartesian for both local
and global points. These can be used to determine the local position
based on the origin/rotation without interpreting it as a r-theta-z
value, for example.

================
  Input format
================

- Streamline dictionary input requirements

  * The default type is cartesian.
  * The default rotation type is the commonly used axes rotation
    specification (with e1/e2/3), which is assumed if the 'rotation'
    sub-dictionary does not exist.

    Example,

    Compact specification:

        coordinateSystem
        {
            origin  (0 0 0);
            e2      (0 1 0);
            e3      (0.5 0 0.866025);
        }

    Full specification (also accepts the longer 'coordinateRotation'
    sub-dictionary name):

        coordinateSystem
        {
            type    cartesian;
            origin  (0 0 0);

            rotation
            {
                type    axes;
                e2      (0 1 0);
                e3      (0.5 0 0.866025);
            }
        }

   This simplifies the input for many cases.

- Additional rotation specification 'none' (an identity rotation):

      coordinateSystem
      {
          origin  (0 0 0);
          rotation { type none; }
      }

- Additional rotation specification 'axisAngle', which is similar
  to the -rotate-angle option for transforming points (issue #660).
  For some cases this can be more intuitive.

  For example,

      rotation
      {
          type    axisAngle;
          axis    (0 1 0);
          angle   30;
      }
  vs.
      rotation
      {
          type    axes;
          e2      (0 1 0);
          e3      (0.5 0 0.866025);
      }

- shorter names (or older longer names) for the coordinate rotation
  specification.

     euler         EulerRotation
     starcd        STARCDRotation
     axes          axesRotation

================
  Coding Style
================
- use Foam::coordSystem namespace for categories of coordinate systems
  (cartesian, cylindrical, indirect). This reduces potential name
  clashes and makes a clearer declaration. Eg,

      coordSystem::cartesian csys_;

  The older names (eg, cartesianCS, etc) remain available via typedefs.

- added coordinateRotations namespace for better organization and
  reduce potential name clashes.

- avoids compiler ambiguity when virtual methods such as
  IOdictionary::read() exist.

- the method was introduced in 1806, and was thus not yet widely used

- improvement documentation for surface sampling.

- can now specify alternative sampling scheme for obtaining the
  face values instead of just using the "cell" value. For example,

      sampleScheme    cellPoint;

  This can be useful for cases when the surface is close to a boundary
  cell and there are large gradients in the sampled field.

- distanceSurface now handles non-closed surfaces more robustly.
  Unknown regions (not inside or outside) are marked internally and
  excluded from consideration. This allows use of 'signed' surfaces
  where not previously possible.

- since PackedBoolList is now a compatibility typedef for bitSet,
  it is useful to have an additional means of distinction.

STYLE: simplify internal version tests and compiler defines.

- the API version is now conveyed via the OPENFOAM define directly.
  The older OPENFOAM_PLUS define is provided for existing code.

- was somewhat redundant in wmake/rules/General/general anyhow

- permits platform-specific override of the general CGAL rules

- primary points for an external user are the polyMesh constructor

- add config info for gcc-7.3.0

COMP: intel-2017. Ignore unknown pragmas. Disambiguate method resolution.

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

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

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:

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.

- otherwise /lib/cpp may need a different library binding than
  currently available and results in this type of error:

  /usr/lib64/gcc/x86_64-suse-linux/4.4/cc1:
  /data/app/OpenFOAM/ThirdParty-1.6.x/platforms/linux64/gcc-4.3.3/lib64/libstdc++.so.6:
  version `GLIBCXX_3.4.11' not found (required by
  /usr/lib64/libppl_c.so.2)

ENH: remove unused flex++ rule for SiCortex that was identical to the
general one anyhow.