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}.

if the user has for some reason old la files from the autotools era,
these can lead to very subtle and hard to understand errors. We now
check for old la files and bail out in case some are found.

Previously, the command vcsetup, which is executed on command 'all',  was not
listed on the help screen.

This reverts commit 9f9bc5c0.

see FS#1576

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 @

We fix the option handling when calling "cmake --build", by prepending '--' to the command
line parameters, in order to separate cmake and build parameters, iff the user didn't alrready do
it himself so. Note that this means we assume that the users generally want to pass
parameters to the build command and not to cmake itself.

This reverts commit eb045a4d.

As it severly breaks using the make build system. See
https://dune-project.org/flyspray/index.php?do=details&task_id=1572

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 makes new automake versions work like old automake versions. Some
of my projects used to compile objects in subdirs from parent directories.
New automake versions don't allow this. We don't want to atopt our
projects to changes in automake and make the transition to cmake... so
keep the old behaviour, by adding this option.

Previously this was only set if run_default_configure was executed
before. Ergo dunecontrol make did try to use cmake even if USE_CMAKE=no
was set. This fixes flyspray 1560.
https://dune-project.org/flyspray/index.php?do=details&task_id=1560

It sets LOCAL_USE_CMAKE for the current module depending on USE_CMAKE
and whether there actually is CMake support for this module.
This will make it more easy to use the same check in all run_*
directives.

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

Previously we did not catch patterns at the start of the line.
Seems like sed cannot handle [ ^] as the meaning of
^ is the not operator here and not the line beginning.

Unfortunately environment variables with these names are not honored by CMake's
FindMPI. Therefore this commit translates them to MPI_{C,CXX}_COMPILER and
adds them to CMAKE_FLAGS before calling cmake.

When deciding which variable to put before cmake as environment variables
our sed pattern did not check for the beginning of a word or line. Therefore
MPICC=bla would be converted to CC=bla.
With this commit we make sure that there is eihter a beginning of a line or
a whitespace before the variable.

This enables ninja-build and other build systems to be called
correctly.
Targets can be passed by adding "--target <targetname>

The warning was spilled out for every module for every command,
even for update.
The build directory is announced by CMake's configure anyway.
Now it is printed for make, too.

CMAKE can now be set in the shell or the opts file, if both are set
the shell has higher priority.
This feature was dropped in …aef001c21e3a9 to fix FS#1518.

"Makefile.in", "*.o", etc. need only be listed in the toplevel .gitignore, the
rules are applied recursively.

Test programs etc. should be listed as "/program" in their directory's
.gitignore, so they are not accidentially ignored in a lower level directory.

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.

The only case we do not want to use the build-dir is
when explicitly autotools are used.

CMAKE is nom handled similar to MAKE.
CMAKE is no longer evaluated in the opts file as this would overwrite
a CMAKE set by the dunecontrol call.
This fixes FS#1518.

Once CMake will be default, people can deactivate it.

dunecontrol is capable of doing out of source builds, that are
not nested within the source directory by giving an absolute path
to the --builddir option. Unfortuantely, this (nice) feature was
not documented.

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.