If the user has given a path to the module, then the system paths should
not be searched, as these may contain an old and outdated version. We
don't necessarily want that just because there was a problem with our
own installation!
This change is similar to commit 89be4e14: After find_package_append_to
changed from function to macro to pick up the configuration not only
from the module itself but also from everything it pulled it, the
variable MODULE is overwritten (variable module in lower case is a
parameter, so it is replaced in the source body). Thus, the test in the
end is not whether *this* module was found, but if its last dependency
was! This made the build crash only in some projects but not in others.
The previous implementation was a function, which although OK from an
implementation standpoint -- the local variables doesn't pollute the
global namespace -- would not allow variables that were set in indirect
dependencies to bubble up to the main module. This is a problem for
modules which are dependent on configuration variables to be present.
If we are on a 64-bits machine, there is no point in searching lib32
and conversely. Quite the opposite, it can only end badly if a library
is actually found in the wrong architecture directory.
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).
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.
If one sets the variable foo_DIR it will cause CMake to look for a
configuration file in that directory. In case we want to set the root
directory to an installation which doesn't have a config-mode CMake
module, and use the find module provided by ourself, we need a separate
variable that can hold the location of this directory and the most
common suffix for this seems to be _ROOT (an alternative is _PREFIX)
Allow arguments to be used on the list of dependencies, this facilitates
searching for things like e.g. Boost, and there is now only need for one
list since REQUIRED can be one of the arguments.
Modules that starts with the prefix "Use" alters the build to enable
something by default, whereas modules that only provide functionality
is not common to start with that prefix.
