Tarballs can be built using "make package_source". But they contain
all files from the source directory. There is a way to ignore files.

We assume anyway that stdint.h and memrory are provided. The
according macros are never used. They were probably provided
to stay as compatible to Autotools as possible.
This fixes FS#1605.

Apparently, that code never for executed/tested...

The file DuneMacros.cmake is very crowded. Macros that belong
together should be placed in a separate module in order to increase
the visibility of its documentation IMO.

With a compiler name given to CMAKE_CXX_COMPILER (instead of a path),
the name is correctly expanded on the first run of cmake, but as soon
as the buil didrectory is existent, it is for obscure reasons expanded
into ${CMAKE_BINARY_DIR}/.... To avoid having users run into this bug,
the expanded compiler variable is matched with the build directory prefix.
In that case, an error is issued.

There is still a warning issued in that case.

Taken from #FS1535, where Carsten has posted this code.

RECOMMENDED created new categories in the summary.
Technically there are no differences.

add symlinks to the build tree, which point to files in the source tree.
Foreach file given in "files", a symlink of that name is created in the
corresponding build directory. Use for ini files, grid files etc. A warning
is issued on Windows systems.

Add a symlink called src_dir to all directories in the build tree.
That symlink points to the corresponding directory in the source tree.
Call the macro from the toplevel CMakeLists.txt file of your project.
You can also call it from some other directory, creating only symlinks
in that directory and all directories below. A warning is issued on
Windows systems.

This way they appear in the summary.

Dominic Kempf authored 10 years ago and Christoph Grüninger committed 10 years ago

The libraries are taken from DUNE_LIBS and from the
global property ALL_PKG_LIBS. This change is necessary
to drop the add_dune_*_flags macros in the future.

With CMake 3.1 variable indication with the @ symbol is
no longer valid, use ${} instead, cf. CMP0053. The @ is
only allowed for configuration files which are transformed.

The generated files are the same with CMake 3.1~rc2 and
CMake 2.8.6.

In dune-grid we want to export the path to the grid example files. To do this
without a handwritten package configuration file, We add a custom section
to it that can be filled by the modules using the variable DUNE_CUSTOM_PKG_CONFIG_SECTION
before finalizing the cmake build system. For dune-grid we export the variable
DUNE_MODULE_SRC_DOCDIR that points to the installed documentation and the path to
the source files of the documenation in the installed and not-installed module, respectively.

Suggested modules are quite often not available and for a large
number of suggested modules the output is very cluttered.
The error message is anyway printed manually.

Dominic Kempf authored 10 years ago and Dominic Kempf committed 10 years ago

Autotools users kept complaining, that it is conceptionally
disappointing that targets cannot be build with flags set upon
entering make (e.g. make CXXFLAGS+="-myflag" mytarget). This
patch introduces a small hack, that allows for such feature
in cmake. It is, however, (at least) questionable whether we
want to include it. Still, for your information and convenience:

To use the feature you must:
- be using a CMake generator that is based on Makefiles (defaults to true)
- set the define ALLOW_EXTRA_CXXFLAGS to true, e.g. by including
  CMAKE_FLAGS="-DALLOW_EXTRA_CXXFLAGS=1" in your optsfile.
- reconfigure your project

cmake will then wrap a small shell script around your compiler
and allow you to append the content of an environment variable
to yout compiler flags. Run for above example:
EXTRA_CXXFLAGS="-myflag" make mytarget

The additional flags will be visually confirmed if and only if
you set the verbosity (as always):
EXTRA_CXXFLAGS="-myflag" make VERBOSE=1 mytarget

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

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.