A typo made it impossible to say 'no'.

Furthermore, I changed the text shown to the user to point to the
module documentation.

Commit 	29405741 accidentally changed the file
permissions to non-executable.

Felix Gruber authored 10 years ago and Christoph Grüninger committed 10 years ago

The install path for header files can be configured in CMake with the
variable ${CMAKE_INSTALL_INCLUDEDIR}.

Felix Gruber authored 10 years ago and Christoph Grüninger committed 10 years ago

Otherwise UNAME_HH was seen by the shell as the name of the variable,
but actually, the variable is called UNAME and _HH should be appended
after expansion of the variable.

Follow up to the previous patch: if the source file contains hyphens, then
the compiled executable should not have them replaced by underscores.

Each module constructed by duneproject contains a little Hello-world example
program.  The name of the program used to be the name of the module with .cc
appended AND all hyphens replaced by underscores.  Hence a module dune-foo
would containt the program dune_foo.cc.  This patch removes that displacement.
Rationale:
- I see no reason for the replacement in the first place
- File names with hyphens appear to be much more common in Dune world than
  file names with underscores.

Felix Gruber authored 10 years ago and Christoph Grüninger committed 10 years ago

add missing @

mention cmake and CMAKE_FLAGS. Add an example for CMAKE_FLAGS in the
example opts file. Also update the compiler version in the example opts
file to a version that is actually supported by dune.

This propbably the best spot to safe the user from himself!

The AmiraMesh format is so obscure that we should not clutter the code we
generate by references to it.  If people really want AmiraMesh support they
can still add the flags, just like they have to do for many other things.

Andreas Nüßing authored 10 years ago and Christoph Grüninger committed 10 years ago

When creating a project and generating the config.h.cmake file, duneproject
surrounds the inserted text with {begin,end} $NAME. $NAME is set to $PROJECT
without a leading "dune[-_]" and $PROJECT is the module name specified by the
user (e.g. $PROJECT==dune-grid, $NAME==grid).
When DuneMacro.cmake generates the config.h.cmake for the created project in
the build-directory, it searches the config.h.cmake file in the source
directory of the project for {begin,end} $ProjectName which is set to
DUNE_MOD_NAME, which is the module name specified in the corresponding
dune.module file (e.g. dune-grid).
This leads to DuneMacro not finding and therefore ignoring the block in the
source config.h.cmake of the new project.

Complained by autoconf 1.14, cf. FS#1462.
Thanks to Claus for the heads-up.

Cf. FS#1461.

Module names with hyphens are no longer changed to
underscores.
This fixes FS#1432.

Fixes flyspray issue 1418, see https://dune-project.org/flyspray/index.php?do=details&task_id=1418

A variable was not correctly escaped during creation of the file
cmake/modules/Makefile.am causing the error message:
"duneproject: line 914: datadir: command not found."

This patch now correctly escapes it.

duneproject failed miserably when run with only installed modules. With
this patch we correctly setup the pkg-config and dunecontrol path to
handle this situation. In addition we fixed various issues with the newly
created modules and they now build as exspected.

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

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.

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.

Update minimal required versions to these mentioned in the documentation.
Quote argument in AC_PREREQ.
(Thanks to Bård Skaflestad for the heads-up)

This is a follow up to the previous patch. It corrects the situation
for new modules created with duneproject.

Fix generated config.cmake.in which contained a surplus endif.
List CMakeLists.txt and other files to be included in tarballs.
Move generated files around to sort them by directory.

Previously we relied on CMake's export(PACKAGE ...) function when
finding dune packages without dune-control. This is error prone
when using several instances of a dune-module (either with differing
versions or built using different options). In this case there is no
control which of the instances is used.

Now we try to guess the correct build directory, if it was not
provided with ${module}_DIR, ${module}_Root or in the
CMAKE_PREFIX_PATH. Note that when using dunecontrol ${module}_DIR will
always be set. We take the path of the current toplevel build
directory and simply substitute any occurence of the name of current
module with name of the module that we try to find. This works for
both  building in a subdirectory of the source tree
(e.g. ${module-source}/build-cmake) or in a sibling directory
containing the module name (e.g. ${module}-build).

[[Imported from SVN: r7450]]

[[Imported from SVN: r7100]]

[[Imported from SVN: r7060]]