- Jan 09, 2014
-
-
Christoph Grüninger authored
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. (cherry picked from commit c1784242) Signed-off-by:
Christoph Grüninger <gruenich@dune-project.org>
-
Markus Blatt authored
(cherry picked from commit e053ef35) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
- Jan 08, 2014
-
-
Markus Blatt authored
(cherry picked from commit 524c2461) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
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. (cherry picked from commit 28a0a956) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit 4360c415) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
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. (cherry picked from commit 6b110c88) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
- Jan 07, 2014
-
-
Markus Blatt authored
Unfortunately gcc-4.4 does not support --print-multiarch. Therefore we fallback to cc -v and grep for the target in this case. (cherry picked from commit 234ba118) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit ca8dc751) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit 1d8ba49d) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit 02e0ab8f) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
DuneCmakePackageConfigHelpers.cmake -> DuneCMakePackageConfigHelpers.cmake (cherry picked from commit 90ebe897) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
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. (cherry picked from commit 4c624058) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
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. (cherry picked from commit cbdd8182) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
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. (cherry picked from commit b118e77f) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit aeca0428) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
Somehow I missed some files when committing. this patch fixes this. (cherry picked from commit 2e987422) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
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. (cherry picked from commit 5dd5e160) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
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 (cherry picked from commit 702aaf31) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
- Jan 06, 2014
-
-
Markus Blatt authored
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. (cherry picked from commit 00aac384) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
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. (cherry picked from commit 127aa0a3) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
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. (cherry picked from commit 709d82d2) Signed-off-by:
Christoph Grüninger <gruenich@dune-project.org>
-
- Jan 04, 2014
-
-
Markus Blatt authored
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. (cherry picked from commit c57e6037) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
git-whitespace-hook is called by dune-control which barks if it is not available. Therefore we distribute and install after this patch. (cherry picked from commit f5c8b490) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
- Jan 03, 2014
-
-
Markus Blatt authored
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. (cherry picked from commit dd2a9b42) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
- Jan 02, 2014
-
-
Markus Blatt authored
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. (cherry picked from commit d7a1f326)
-
Markus Blatt authored
Previously, dependencies were not correctly searched for as required packages. This patch fixes this. (cherry picked from commit 86f1dc9c)
-
Christoph Grüninger authored
This fixes FS#1404. (cherry picked from commit 862b6d93) Signed-off-by:
Christoph Grüninger <gruenich@dune-project.org>
-
- Dec 28, 2013
-
-
(cherry picked from commit ccb09bea) Signed-off-by:
Christoph Grüninger <gruenich@dune-project.org>
-
Christoph Grüninger authored
(cherry picked from commit 518f3fc2) Signed-off-by:
Christoph Grüninger <gruenich@dune-project.org>
-
- Dec 20, 2013
-
-
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. (cherry picked from commit 79cc2c42) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
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. (cherry picked from commit e258dbd6) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
- Dec 19, 2013
-
-
Markus Blatt authored
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. (cherry picked from commit f9ce322c) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit 6a2cf7da) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit 4120a7f3) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
- Dec 18, 2013
-
-
Markus Blatt authored
This completes the last patch where we moved its installation directory by reflecting the new location in the package configuration. (cherry picked from commit 69352ecc) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit d5adf804) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit a897d8f9) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
docdir is variable of automake and its by default set to $(datadir)/doc/dune-common. Therefore there is not need to set it here. (cherry picked from commit 7655d4f6) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
(cherry picked from commit 6d806c78) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-
Markus Blatt authored
When moving the documentation of the parallel index sets from dune-istl to dune-common, we forgot to adjust the installation directories accordingly. This patch fixes this situation. (cherry picked from commit 6b30e8f7) Signed-off-by:
Markus Blatt <markus@dr-blatt.de>
-