With this patch the default is again building static libraries unless
one specifies -DBUILD_SHARED=True to cmake. This is not a fix but a
workaround for flyspray #1429
https://dune-project.org/flyspray/index.php?do=details&task_id=1429

Previously running make test if there was a symlink int the path to the module.
This caused make test to fail. This patch fixes this by extracting the
path without symlinks.

Dependencies in the dune.module without a required version failed.

Now <= and >= are correctly treated.

Du to typo the length of the modules and version list of the suggestion
differed. This patch fixes this.

If we do not do that the length of the list of modules and corresponding versions
will differ as empty values will be neglected when appending to a list

In this patch we rename dune_process_depedency_tree to
dune_process_depedency_macros because it actually just
include the macros of all modules that we depend on.
I addition we fix a bug that resulted in not executing the module's
own macro if there was only one dependency and now always process
it here.

Somehow we ended up putting CMAKE_PROJECT_SOURCE_DIR/lib into the
linker path. There should not be any library there and it should
not be needed for linking anyway. Additionally it causes warnings
in dune-grid-howto. Therefore this patch simply removes it.

The name of the file changed in one of the recent patches. This
change is now also reflected in the install directive. Fixes #1426

Previously, we used >=0.0. if there was no version information in the
dependes and suggests clause of a dune.module file. This breaks with
the new more strict version checking. Therefore with this revision no
version gets set if it does not appear in dune.module

Before we tried to search for dune-common twice (once without a version
and then with the required version). Unfortunately this breaks because
we are adding the same library target twice. With this patch we only
search for a module once.

Before this patch we always relied on dunecontrol/pkg-config to check
for the correct version. With this patch we include this functionality
also when building packges with dunecontrol for this use part of the version
checking of cmake (or pkg-config if there are packages without CMake support).
Basically we let CMake check wether the major and minor version matches and
afterwards use the information from the dune.module file. This should make
it possible to have several versions of DUNE installed and still always use
the correct version. During fixing these issues we noticed that our version
files were not recognized because the carried the wrong name. Now we use the
correct name <dune-module>-config-version.cmake.

This fixes FS#1422.

Replace tabs by spaces.

One of the latest patches prevent the macros of the current module
form being executed. This patch fixes this by including the module
in the dependency tree.

When making the entries of ALL_DEPENDENCIES unique, we skipped modules that
did not ship a Dune<ModuleName>Macros.cmake macro. This caused their libraries
to be missing in DUNE_LIBS. This patch fixes this situation.

Previously we already processed dune.module but in a much later stage during
configure. Dependencies are contained in dune.module. Therefore there is no
need to replicate them in the CMake package configuration files. With this
patch we now always process dune.module directly after finding the DUNE module.
In addition we set ${DUNE_MOD_NAME}_(DEPENDS|SUGGESTS} in the CMake environment.
As with this change DUNE_MOD_NAME will usually be set to to dune-common, we
also changed to using ProjectName and ProjectVersion (the canonical CMake names)
to refer to the current module and version.

Previously we checked whether the extracted Version evaluated to
True. Unfortunately, there lazy people like me that like use a version
of 0 for testing, which evaluates to False and breaks configure.
With this patch we allow 0 to and just test wether the version consists
of characters.

With new modules there were cases where cmake/modules was not in the
modules path which made configuration fail. This patch fixes this case.

Some ^[$BLANK] or [^[$BLANK]^'], where $BLANK is space followed by tab
did not work as a capturing statement in some cases (e.g. opts files
with CONFIGURE_FLAGS="CXX='bla'"). After this patch we use [$NOBLANK]
with NOBLANK=^$space^$tab which works. In addition the other patches
form feature/posix-sed-dunecontrol have been backported to close flyspray
1401.

DuneCmakePackageConfigHelpers.cmake -> DuneCMakePackageConfigHelpers.cmake

Apparently it is not available with some older versions of CMake.
Therefore we provide a poor man's alternative for it, if it is
not there.

Debian uses multiarch-triplets (e.g. i386-gnu-linux) when installing
object libraries. These are installed to lib/$multiarch-triplet and not
to lib directly. In CMake this concept is partially supported by
GNUInstallDirs.cmake by setting CMAKE_INSTALL_LIBDIR to
lib/$multiarch-triplet. Unfortunately, this is only half the way through
as we also install libraries that do not differ between architectures (e.g.
our shell libraries.

This patch addes multiarch support for CMake to the best of my knowledge,
which might be limited, though:

- All not architecture dependent libraries are installed below the variable
  DUNE_INSTALL_NONOBJECTLIBDIR, which defaults to lib, but might be adjusted
  by the user.
- If the module ships an object library then the pkg-config and CMake package
  configuration files are installed in lib/$multiarch-triplet/pkg-config and
  lib/$multiarch-triplet/cmake/modules, respectively.
- If not then they are installed in lib/pkg-config and
  lib/cmake/modules, respectively.

Note that for autotool no such difference exists and always the latter approach
is used.

Somehow I missed some files when committing. this patch fixes this.

Previously, the macros were installed to $(datadir)/cmake/. As we have
some macros in DUNE that might also be in other packages
this may cause conflicts in package managers. With this patch we install
them to $(datadir)/dune/cmake to resolve this issue. Together with the
last patch this will resolve problems  outlined in flyspray
task 813
https://dune-project.org/flyspray/index.php?do=details&task_id=813
I apologize for givin the wrong task number in the previous patch.

As Ansgar not the CMake package configuration files are quite generic. This
patch autogenerates them if their templates do not exist in the source tree.
In addition duneproject and am2cmake do not generate the templates as files
in the source tree anymore.

At least for dune-common the CMAKE_MODULE_PATH may be empty
and removing an item from an empty list is an error. This
patch fixes this issue by checking whether th list is empty.

Previously, dependencies were not correctly searched for as
required packages. This patch fixes this.

When working with installed modules, the cmake scripts and
modules of the current module should take precendence over
any installed ones. This was not the case before this patch.

Furthermore, modules downstream in the
dependency tree should be able to overwrite tests in  modules
that they depend on. This patch more caredfully crafts the
CMAKE_MODULE_PATH to reflect the module dependency in it.

Steffen Müthing authored 11 years ago and Markus Blatt committed 11 years ago

Previoulsy CMake always fails to find the __gmpz_abs symbol on my machine, even though it is clearly there.
The test used check_symbol_exists. According to the documentation, check_symbol_exists tries to include the
second argument into a test program to check whether there is a prototype for the first argument, so as the
second argument is a binary, that can't really work... This patch switches over to use check_library_exists.

For generating the config.h file we use the HAVE_* variables instead
of the CMake ones *_FOUND, Unfortunately, we sometines to not set
HAVE_* to the value of the *_FOUND vriable but to its name. Usually
we only query whether these variable are set at all. While
this often (except for psurface) does not pose a problem, it is semantically
wrong. Therfore this patch fixes this.

Kudos to Ansgar for pointing to this problem.

This completes the last patch where we moved its installation directory by
reflecting the new location in the package configuration.