Somehow, the vector version of CollectiveCommunication< MPI_Comm >::prod
passed std::plus to allreduce (instead of std::multiplies). This patch
corrects this flaw.

Previously some of the pathes (e.g the multiarch ones) took precedence
over the others. But as with same some of the pkgconfig files are installed
below lib/<multiarch> and others (if there is not object library) are not.
With this patch all possible install locations of pkgconfig files are added
to the path if they exist.

With openSuse 12.3 (Doxygen 1.8.5) the generated documentation contains
lots of huge graphs which show the include dependency graph of a file.
This lead to large tarballs of 155 MiB compared to 50 MiB with this
patch.
With Debian Wheezy (Doxygen 1.8.1.2) the tarballs did not blow up in
file size. Scanning the Doxygen change log did not enlighten me and
I remain puzzled why the graph were never built.

INCLUDED_BY_GRAPH is changed to prevent the same behvior for future
releases. We currently do not include these graphs and this change
makes the configureation consistent with the result.

The compiler might exit with nonzero exit code if given non-existent
options. Therefore we need to use set +e during this to make dunecontrol
to continue running even the options are not supported.

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.

Unfortunately gcc-4.4 does not support --print-multiarch.
Therefore we fallback to cc -v and grep for the target in this case.

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.

Previously aclocal did not find the DUNE macros when they were installed to
the new location. This patch fixes this by adding the path to this list of
include paths if it is available.

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.

Previously, the macros were installed to $(datadir)/aclocal. As we have
some macros in DUNE that are also installed for some Linux distributions
this caused conflicts in package managers. With this patch we install
them to $(datadir)/dune/aclocal to resolve this issue outlined in flyspray
task 1409
https://dune-project.org/flyspray/index.php?do=details&task_id=1409

When unpacking the tarballs, the time stamps are preserved, but the
access time of the files might be set differently. In addition during
configure Doxyfile is always created. This resulted in some files being
newer than the doxygen-tag in the tarball and triggered building the
documentation. This patch fixes the problem for me by only checking the
modification time and excluding Doxyfile.

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.

Make type of std::site_t an additional template parameter to avoid the
warning. While this is conceptually redunant its OK since we only use
it in a helper struct.

Previously only the include path of the local modules were used. This
caused errors with installed dune-common modules, similar to:

--> aclocal...

Error: Could not find dune-common/am!
Usage: dune-autogen DUNE_MODULE_PATH_LIST [options]
  --ac=, --acversion=VERSION   use a specific VERSION of autoconf
  --am=, --amversion=VERSION   use a specific VERSION of automake
  -h,    --help                you already found this :-)
--- Failed to build dune-typetree ---
Terminating dunecontrol due to previous errors!

This is also related to https://dune-project.org/flyspray/index.php?do=details&task_id=891

With this patch we include the aclocal, m4 or am directory of all modules
(installed and local ones) and everything works again as exspected.

git-whitespace-hook is called by dune-control which barks if
it is not available. Therefore we distribute and install after
this patch.

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.

This fixes FS#1404.

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.

The cause for the problem was the introduction of cmake/modules. This caused
the find statement to always print something. This patch simply excludes
cmake/modules from the result with grep -v.