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.
Some libraries require more information than what is present in the
xxx-config.cmake file, e.g. the caller must know whether HAVE_TUPLE
is available and probably used when compiling dune-common, and put
this in its own config.h file.
Code to take care of these variables must therefore be in the client
configuration, and this is the same code which is used to handle the
autotools version, namely the find module, so a practical solution
is to just revert to that in both cases.
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.
Originally, I added FindSuperLU with uppercase since the variables it
returned had that case. Now the scripts should be patched so that it
searched for uppercase amongst the variables as well, so the module
name can retain its original case (and for compatibility with DUNE)
For compatibility with packages that believes that every variable
should be in uppercase, we try this variant when adding relevant
variables to the project.
A substring can of course not be longer that the full string. Also fixes
problems with CMake-versions that doesn't handle out-of-range parameters
to the SUBSTRING sub-command.
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.
dunecontrol will check for a dune.module file to regard the directory
as containing the module. If we put this is a sub-dir of the source,
it will get confused, so we shouldn't. There shouldn't be any
conflicting use-cases, as one cannot have several modules in the sub-
directory of one source (!?).
Instead of having the name of the module set for each flag, use the
available standard option. Mixing shared objects and static libraries
in the same build is not a very realistic scenario anyway.
This enables us to call configure without actually having a particular
module; the script may then be used on a group level.
