There were (at least) three implementations of the same macro; these
have been collected into a separate helper module. (Note that this
means that FindERT is now not completely stand-alone anymore).
If you specified options in an environment variable containing a blank
at the end, then this would not compare equal to the other candidate,
which was stripped, causing the first added argument to drop out! This
is usually the flag for C++11 compliance, causing binary incompatibility
The previous version did the test and setting of the config variable
right, but reported that the module was found only if the files were
located, independently of the result of the compile.
When generating the config.h configuration file, write to a temporary
first and then rename afterward to avoid touching the file and thus
triggering a complete rebuild (of everything that includes config.h)
unnecessarily.
Files which constitutes compilation units are now specified explicitly
in the file CMakeLists_files.cmake rather than identified through a
glob. If this file is updated, a reconfigure should be triggered.
This also enables us to specify exactly which headers that should be
distributed as part of the installation package, and which programs
that should be used for unit testing.
Options are boolean flags that are stored... in the cache, whereas
cache variables are also stored in the cache, but can have a variety
of types (including booleans). It was possible to confuse the two,
because if you set it as a variable on the command line, it will
override both.
Previously the directory name was just entered as part of a glob; the
new version uses the satellite name as a directory and also makes sure
that this directory is available to run tests in, even if there are no
datafiles (the directory itself is now considered a datafile)
Most of the file is not changed from some sensible default anyway, so we
can store this in the template directory and have a much more manageable
local file which just contains the relevant changes.
The WORKING_DIRECTORY property wasn't added until 2.8.4; for versions
earlier than that we provide a work-around. On newer versions we set the
property since some other components may use it.
If libumfpack.so does not declare an explicit dependency on libamd.so,
the linker option -Wl,--as-needed will cause an undefined reference
since we don't use libamd.so ourself. If the configuration determines
that this may be the case, a linker option that forces linking the the
AMD library is added for the SuiteSparse library, and the general
configuration then gets out of the way if this is set.
Not all Linux distributions is LSB-compliant, notably RHEL 6, so we
should make an effort to check various known other files in order to
identify the distribution.
