From: heltai
Date: Thu, 29 Aug 2013 10:34:57 +0000 (+0000)
Subject: Merged from trunk
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4f080c6b6d159e8ce04c074dde4b32c4e1fe2148;p=dealii-svn.git
Merged from trunk
git-svn-id: https://svn.dealii.org/branches/branch_manifold_id@30524 0785d39b-7218-0410-832d-ea1e28bc413d
---
diff --git a/deal.II/doc/development/CMakeLists.txt.sample b/deal.II/doc/development/CMakeLists.txt.sample
deleted file mode 100644
index 549cf0d0bb..0000000000
--- a/deal.II/doc/development/CMakeLists.txt.sample
+++ /dev/null
@@ -1,61 +0,0 @@
-## ##
-# A simple CMakeLists.txt file for use with deal.II #
-## ##
-
-#
-# Set the name of the project and target:
-#
-SET(TARGET "step-1")
-
-#
-# Declare all source files the target consists of:
-#
-SET(TARGET_SRC
- ${TARGET}.cc
- # You can specify additional files here!
- )
-
-#
-# (Optional)
-# Specify a list of files (file globs) that will be removed
-# with the "make runclean" and "make distclean" targets.
-# If empty, sensible default values will be used.
-#
-SET(CLEAN_UP_FILES
- # a custom list of globs, e.g. *.log *.vtk
- )
-
-#
-# (Optional)
-# A custom command line that should be invoked by "make run". If empty,
-# ./${TARGET} will be invoked.
-#
-SET(TARGET_RUN
- # a custom command line, e.g. mpirun -np 2 ${TARGET}
- )
-
-#
-# It is good practice to specify a version requirement:
-#
-CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
-
-#
-# Find and import the deal.II project configuration:
-#
-FIND_PACKAGE(deal.II 8.0 REQUIRED
- HINTS
- ${DEAL_II_DIRS} ../ ../../ $ENV{DEAL_II_DIR}
- #
- # If the deal.II library cannot be found (because it is not installed at a
- # default location or your project resides at an uncommon place), you
- # can specify additional hints for search paths here, e.g.
- # "$ENV{HOME}/workspace/deal.II"
- #
- )
-
-#
-# And let deal.II do the rest:
-#
-DEAL_II_INITIALIZE_CACHED_VARIABLES()
-PROJECT(${TARGET})
-DEAL_II_INVOKE_AUTOPILOT()
diff --git a/deal.II/doc/development/CMakeLists.txt.sample1 b/deal.II/doc/development/CMakeLists.txt.sample1
new file mode 100644
index 0000000000..fda35efbf6
--- /dev/null
+++ b/deal.II/doc/development/CMakeLists.txt.sample1
@@ -0,0 +1,20 @@
+FIND_PACKAGE(deal.II 8.0 REQUIRED
+ HINTS
+ ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
+ # You can specify additional hints for search paths here, e.g.
+ # $ENV{HOME}/workspace/deal.II
+ )
+
+# Set the name of the project and target:
+SET(TARGET "step-1")
+
+# Declare all source files the target consists of:
+SET(TARGET_SRC
+ step-1.cc
+ # You can specify additional files here!
+ )
+
+CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
+DEAL_II_INITIALIZE_CACHED_VARIABLES()
+PROJECT(${TARGET} CXX)
+DEAL_II_INVOKE_AUTOPILOT()
diff --git a/deal.II/doc/development/CMakeLists.txt.sample2 b/deal.II/doc/development/CMakeLists.txt.sample2
new file mode 100644
index 0000000000..2003f225e9
--- /dev/null
+++ b/deal.II/doc/development/CMakeLists.txt.sample2
@@ -0,0 +1,33 @@
+FIND_PACKAGE(deal.II 8.0 REQUIRED
+ HINTS
+ ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
+ # You can specify additional hints for search paths here, e.g.
+ # $ENV{HOME}/workspace/deal.II
+ )
+
+# Set the name of the project and target:
+SET(TARGET "step-1")
+
+# Declare all source files the target consists of:
+SET(TARGET_SRC
+ step-1.cc
+ # You can specify additional files here!
+ )
+
+# Specify a list of files (file globs) that will be removed
+# with the "make runclean" and "make distclean" targets.
+# (If empty, sensible default values will be used.)
+SET(CLEAN_UP_FILES
+ # a custom list of globs, e.g. *.log *.vtk
+ )
+
+# A custom command line that should be invoked by "make run".
+# (If empty, ./${TARGET} will be invoked.)
+SET(TARGET_RUN
+ # a custom command line, e.g. mpirun -np 2 ${TARGET}
+ )
+
+CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
+DEAL_II_INITIALIZE_CACHED_VARIABLES()
+PROJECT(${TARGET} CXX)
+DEAL_II_INVOKE_AUTOPILOT()
diff --git a/deal.II/doc/development/CMakeLists.txt.sample3 b/deal.II/doc/development/CMakeLists.txt.sample3
new file mode 100644
index 0000000000..7d484c182f
--- /dev/null
+++ b/deal.II/doc/development/CMakeLists.txt.sample3
@@ -0,0 +1,15 @@
+CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
+
+FIND_PACKAGE(deal.II 8.0 REQUIRED
+ HINTS ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
+ )
+
+DEAL_II_INITIALIZE_CACHED_VARIABLES()
+PROJECT(step-1 CXX)
+
+ADD_EXECUTABLE(step-1 step-1.cc)
+DEAL_II_SETUP_TARGET(step-1)
+
+ADD_CUSTOM_TARGET(run COMMAND step-1
+ COMMENT "Run with ${CMAKE_BUILD_TYPE} configuration"
+ )
diff --git a/deal.II/doc/development/cmake-internals.html b/deal.II/doc/development/cmake-internals.html
index 903af06bfa..fbfdbab628 100644
--- a/deal.II/doc/development/cmake-internals.html
+++ b/deal.II/doc/development/cmake-internals.html
@@ -11,157 +11,155 @@
-
-
-
-
Build system internals
-
-
- This page provides details about the CMake build system. Files
- processed by the top level CMakeLists.txt script are
- listed in the TOC in chronological order.
-
- CMake operates almost always with variables in global state. To guard
- against accidental overwrite of variables the following naming
- conventions must be followed at all times:
-
-
- Global (configuration) variables are written in all caps. When
- introducing a new one, ensure that the name isn't already used
- somewhere else. Unrelated global variables must never be
- overwritten.
-
- Global variables can be prefixed by DEAL_II_.
- (Global variables defined by CMake are usually prefixed by
- CMAKE_.)
-
- Local variables should always be named in all lowercase with a
- leading "_". Local variables cannot be assumed to remain valid.
- The may get overwritten at any time.
-
-
-
-
-
-
./CMakeLists.txt and ./cmake/setup_*.cmake
-
-
- The very first configuration steps after some initial setup in
- ./CMakeLists.txt takes place in some
- ./cmake/setup_*.cmake files:
-
-
setup_cached_variables.cmake:
- This sets up all cached variables prior to the call to
- PROJECT(deal.II). For details see the comment at the
- top. Furthermore, some bookkeeping for compiler and linker flags
- takes place, see the section
- about compile flags.
-
setup_deal_ii.cmake:
- This file is included immediately after the call to
- PROJECT(deal.II) and will set up all magic
- numbers such as names, definitions, relative and absolute
- paths used in the build system. Most of the definitions are
- guarded with the help of the SET_IF_EMPTY macro so
- that it is possible to override the values from the command line.
-
setup_compiler_flags.cmake
- sets up a suitable set of default compile flag for a known
- compiler by including the appropriate
- setup_compiler_flags_*.cmake file. When adding new
- flags or compiler support, please respect the following note
-
+
+
Build system internals
+
+
+ This page provides details about the CMake build system. Files
+ processed by the top level CMakeLists.txt script are
+ listed in the TOC in chronological order.
+
+ CMake operates almost always with variables in global state. To
+ guard against accidental overwrite of variables the following naming
+ conventions must be followed at all times:
+
+
+
+
+ Global (configuration) variables are written in all caps. When
+ introducing a new one, ensure that the name isn't already used
+ somewhere else. Unrelated global variables must never be
+ overwritten.
+
+ Global variables can be prefixed by DEAL_II_.
+ (Global variables defined by CMake are usually prefixed by
+ CMAKE_.)
+
+ Local variables should always be named in all lowercase with a
+ leading "_". Local variables cannot be assumed to remain valid.
+ The may get overwritten at any time.
+
+
+
+
Configuration
+
+
+
./CMakeLists.txt and ./cmake/setup_*.cmake
+
+
+ The very first configuration steps after some initial setup in
+ ./CMakeLists.txt takes place in some
+ ./cmake/setup_*.cmake files:
+
+
setup_cached_variables.cmake:
+ This sets up all cached variables prior to the call to
+ PROJECT(deal.II). For details see the comment at the
+ top. Furthermore, some bookkeeping for compiler and linker flags
+ takes place, see the section
+ about compile flags.
+
setup_deal_ii.cmake:
+ This file is included immediately after the call to
+ PROJECT(deal.II) and will set up all magic
+ numbers such as names, definitions, relative and absolute
+ paths used in the build system. Most of the definitions are
+ guarded with the help of the SET_IF_EMPTY macro so
+ that it is possible to override the values from the command line.
+
setup_compiler_flags.cmake
+ sets up a suitable set of default compile flag for a known
+ compiler by including the appropriate
+ setup_compiler_flags_*.cmake file. When adding new
+ flags or compiler support, please respect the following note
+
+
- The next step in the configuration process is to include all
- checks residing under ./cmake/checks. Currently
- there are:
-
+
+ The next step in the configuration process is to include all
+ checks residing under ./cmake/checks. Currently
+ there are:
+
+
./cmake/checks/check_01_compiler_features.cmake
- Search for support for compiler dependent features such as stack
trace support, demangler support, etc.
@@ -240,24 +239,27 @@
./cmake/checks/check_02_compiler_bugs.cmake
- Check for compiler bugs
-
-
-
- A check usually consists of a call to one of the macros below
- that will set up a global variable. Please stick to the naming
- convention HAVE_<..>, resp.
- DEAL_II_(HAVE|USE)_<..>. It is forbidden to
- use a variable name starting with
- DEAL_II_WITH_<..> because this prefix is
- exclusively reserved for the feature mechanism described
- below. For some tests it might be necessary to manipulate global variables.
-
- A platform check should have a prominent comment explaining what
- it does and why it is there, and should state author and year.
-
- There are a number of readily available platform check macros:
-
+
+
+
+
+
+ A check usually consists of a call to one of the macros below
+ that will set up a global variable. Please stick to the naming
+ convention HAVE_<..>, resp.
+ DEAL_II_(HAVE|USE)_<..>. It is forbidden to
+ use a variable name starting with
+ DEAL_II_WITH_<..> because this prefix is
+ exclusively reserved for the feature mechanism described
+ below. For some tests it might be necessary to manipulate
+ global variables.
+
+ A platform check should have a prominent comment explaining what
+ it does and why it is there, and should state author and year.
+
+ There are a number of readily available platform check macros:
+
+
CHECK_CXX_SOURCE_COMPILES(source variable)
- Checks whether it is possible to compile _and_ link the code snippet
@@ -291,65 +293,67 @@
CHECK_CXX_COMPILER_FLAG(flag variable)
- Sets the variable to 1 if the compiler understands the flag.
-
-
Necessary compiler flags can easily set in the string variable
- CMAKE_REQUIRED_FLAGS. There are two small macros
- that do this job nicely:
-
+
+
+
Necessary compiler flags can easily set in the string variable
+ CMAKE_REQUIRED_FLAGS. There are two small macros
+ that do this job nicely:
+
Necessary include directories and libraries necessary for
- linkage can be set in the list variables
- CMAKE_REQUIRED_INCLUDES and
- CMAKE_REQUIRED_LIBRARIES. It is best to append these
- lists and later on reset CMAKE_REQUIRED_* (including
- CMAKE_REQUIRED_FLAGS) to their default values:
-
+
Necessary include directories and libraries necessary for
+ linkage can be set in the list variables
+ CMAKE_REQUIRED_INCLUDES and
+ CMAKE_REQUIRED_LIBRARIES. It is best to append these
+ lists and later on reset CMAKE_REQUIRED_* (including
+ CMAKE_REQUIRED_FLAGS) to their default values:
+
+
LIST(APPEND CMAKE_REQUIRED_INCLUDES <a list of includes>)
LIST(APPEND CMAKE_REQUIRED_LIBRARIES <a list of libraries>)
CHECK_CXX_SOURCE_COMPILES(...)
RESET_CMAKE_REQUIRED()
-
-
-
-
-
-
-
-
./cmake/modules/Find*.cmake
-
-
- These are find modules for the configure_*.cmake files
- and the CONFIGURE_FEATURE macro as will explained later.
- It is crucial that a find module behaves correctly. Therefore, the
- following rules are mandatory:
-
-
- The sole purpose of a find module is to find an external
- library (no deal.II specific dependency checking, no
- compatibility checking).
-
- It should do so by appropriate FIND_LIBRARY and
- FIND_PATH calls. The results of this calls should be the
- only cached variables.
-
- FIND_PACKAGE_HANDLE_STANDARD_ARGS should be used for
- setting FEATURE_FOUND as this already respects the
- QUIET and REQUIRED keywords.
-
- A WARNING, SEND_ERROR or
- FATAL_ERROR must be avoided (the only exception is
- the REQUIRED keyword).
-
- If successful, the following uncached variables might be set:
-
-
+
+
+
+
+
+
./cmake/modules/Find*.cmake
+
+
+ These are find modules for the configure_*.cmake files
+ and the CONFIGURE_FEATURE macro as will explained later.
+ It is crucial that a find module behaves correctly. Therefore, the
+ following rules are mandatory:
+
+
+ The sole purpose of a find module is to find an external
+ library (no deal.II specific dependency checking, no
+ compatibility checking).
+
+ It should do so by appropriate FIND_LIBRARY and
+ FIND_PATH calls. The results of this calls should be the
+ only cached variables.
+
+ FIND_PACKAGE_HANDLE_STANDARD_ARGS should be used for
+ setting FEATURE_FOUND as this already respects the
+ QUIET and REQUIRED keywords.
+
+ A WARNING, SEND_ERROR or
+ FATAL_ERROR must be avoided (the only exception is
+ the REQUIRED keyword).
+
+ If successful, the following uncached variables might be set:
+
+
- There are obviously valid exceptions from this rule, though.
-
- Only "local" variables "_<all lowercase>" or
- "global" variables prefixed by FEATURE_ may be
- altered. Do not set DEAL_II_* or CMAKE_*
- variables directly!
-
- A hint with FEATURE_DIR can be set up for
- convenience. It is best to start the Find module by
-
- and use FEATURE_DIR as a hint. If the external
- library could be found, hide it via
- MARK_AS_ADVANCED, if the external library could not
- be found, set a cache value:
-
-
- SET(FEATURE_DIR "" CACHE PATH "An optional hint to a FEATURE directory")
-
-
+
+There are obviously valid exceptions from this rule, though.
+
+ Only "local" variables "_<all lowercase>" or
+ "global" variables prefixed by FEATURE_ may be
+ altered. Do not set DEAL_II_* or CMAKE_*
+ variables directly!
+
+ A hint with FEATURE_DIR can be set up for
+ convenience. It is best to start the Find module by
+
-
-
./cmake/configure/configure_*.cmake
+ SET_IF_EMPTY(FEATURE_DIR "$ENV{FEATURE_DIR}")
+
+
+and use FEATURE_DIR as a hint. If the external
+library could be found, hide it via
+MARK_AS_ADVANCED, if the external library could not
+be found, set a cache value:
+
+
+ SET(FEATURE_DIR "" CACHE PATH "An optional hint to a FEATURE directory")
+
+
-
- The final step in the configuration phase is the setup of features
- (which refer to external or bundled libraries
- deal.II can optionally interface with.)
-
+
+
./cmake/configure/configure_*.cmake
+
+
+ The final step in the configuration phase is the setup of features
+ (which refer to external or bundled libraries
+ deal.II can optionally interface with.)
+
+
At bare minimum configure_<feature>.cmake
@@ -574,7 +580,8 @@
- cmake is the configuration and build tool we use
- in deal.II. Its advantage is not only that it makes
- configuration of deal.II itself simpler across
- platforms (compared to the older autoconf/make combination)
- but also that it exports information about the deal.II
- configuration that makes it particularly simple for projects
- using deal.II to configure and link against it.
-
+ cmake is the configuration and build tool we use
+ in deal.II. Its advantage is not only that it makes
+ configuration of deal.II itself simpler across
+ platforms (compared to the older autoconf/make combination)
+ but also that it exports information about the deal.II
+ configuration that makes it particularly simple for projects
+ using deal.II to configure and link against it.
+
+
+
+ cmake is controlled by input files that by convention are
+ called CMakeLists.txt, listing both configuration commands
+ as well as dependencies between source files and targets.
+ This page presents some CMakeLists.txt examples for
+ potential use in your projects. (A detailed description of the
+ deal.II project configuration is given in the
+ deal.II CMake ReadMe.)
+
+
+
+
Simple CMakeLists.txt
+
+
+ In this section, we start out with a
+ minimal CMakeLists.txt based on
+ the DEAL_II_SETUP_TARGET macro. This method gives
+ full control of what's happening and is easily extensible to
+ more complex projects, as exemplified in the subsections here an
+ later in the section on advanced
+ topics. Here is a full example
+ (plain text
+ version):
+
+
+ The first line of this code makes sure that a sufficiently high
+ version of CMake is installed. 2.8.8 is the minimal version required
+ to set up deal.II, therefore it is safe to use this
+ number here.
+
+
+
+ Next, we find our deal.II installation, in this case requiring at
+ least version 8.0, which is the first version using
+ CMake. The HINTS are a list of directories where the
+ install directory of deal.II is likely to be found. Here, we check
+ whether we are in a subdirectory (first and second level) of the
+ deal.II installation and otherwise use the
+ variable DEAL_II_DIR.
+ Matthias, what is the difference between the first
+ and the last entry? This list can be changed according to your
+ preferences. After finding the deal.II project, we fetch its chached
+ variables. You can inspect these for instance
+ with ccmake.
+
+
+
+ Every CMAkeLists.txt must contain a project definition,
+ which we do next. Matthias, I have been happy
+ without the CXX...?
+
+
+
+ Finally, the last two lines define the executable that is to be
+ produced and its source code.
+
+
+
+
Explain the macros or link to explanation below
+
+
+
Adding multiple executable targets
+
+
+ In order to specify multiple executable targets, simply repeat
+ the last two lines of the simple CMakeLists.txt:
+
+
+If the list gets longer, consider using
+a loop, possibly
+with GLOB.
+
+
+
Adding libraries and common source files
- cmake is controlled by input files that by convention are
- called CMakeLists.txt, listing both configuration commands
- as well as dependencies between source files and targets.
- This page presents some CMakeLists.txt examples for
- potential use in your projects. A detailed description of the
- deal.II project configuration is given in the
- deal.II CMake ReadMe.
+ Adding a library is as simple as adding an executable target. We
+ specify the library name and then have to tell cmake that the
+ executables depend on it. The code in the simple file below the
+ project definition accordingly changes for instance to:
-
-
Simple CMakeLists.txt
-
-
- The easiest way to write a CMakeLists.txt file is to use
- an "autopilot" style macro. Here is an example for the step-1
- tutorial program (plain text version) that can be used for simple
- projects:
-
-
- #
- # Set the name of the project and target:
- #
- SET(TARGET "step-1")
-
- #
- # Declare all source files the target consists of:
- #
- SET(TARGET_SRC
- ${TARGET}.cc
- # You can specify additional files here!
- )
-
- #
- # (Optional)
- # Specify a list of files (file globs) that will be removed
- # with the "make runclean" and "make distclean" targets.
- # If empty, sensible default values will be used.
- #
- SET(CLEAN_UP_FILES
- # a custom list of globs, e.g. *.log *.vtk
- )
-
- #
- # (Optional)
- # A custom command line that should be invoked by "make run". If empty,
- # ./${TARGET} will be invoked.
- #
- SET(TARGET_RUN
- # a custom command line, e.g. mpirun -np 2 ${TARGET}
- )
-
- #
- # It is good practice to specify a version requirement:
- #
- CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
-
- #
- # Find and import the deal.II project configuration:
- #
- FIND_PACKAGE(deal.II 8.0 REQUIRED
- HINTS
- ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
- #
- # If the deal.II library cannot be found (because it is not installed at a
- # default location or your project resides at an uncommon place), you
- # can specify additional hints for search paths here, e.g.
- # "$ENV{HOME}/workspace/deal.II"
- #
- )
-
- #
- # And let deal.II do the rest:
- #
- DEAL_II_INITIALIZE_CACHED_VARIABLES()
- PROJECT(${TARGET})
- DEAL_II_INVOKE_AUTOPILOT()
-
+
+ADD_LIBRARY(mylib libsrc1.cc libsrc2.cc libsrc3.cc)
- This CMakeLists.txt is intended for use with a small
- project and in-source build (i.e., one does not create a separate
- build directory as we recommend for the deal.II build
- in the readme
- file). Using this input file, you can run cmake in the
- source directory as follows:
-
- $ cd step-1
- $ cmake .
-
- [...]
-
- ###
- #
- # Successfully set up project step-1 with deal.II-8.0.pre found at
- # /usr/local
- #
- # CMAKE_BUILD_TYPE: Debug
- # TARGET_SRC: step-1.cc
- #
- # You can now run
- # $ make - to compile and link the program
- # $ make run - to (compile, link and) run the program
- #
- # $ make debug - to switch the build type to "Debug"
- # $ make release - to switch the build type to "Release"
- # $ make edit_cache - to change (cached) configuration variables
- # and rerun the configure and generate phases of CMake
- #
- # $ make clean - to remove the generated executable as well as
- # all intermediate compilation files
- # $ make runclean - to remove all output generated by the program
- # $ make distclean - to clean the directory from _all_ generated
- # files (includes clean, runclean and the removal
- # of the generated build system)
- #
- # Have a nice day!
- #
- ###
-
-
+
When you have multiple targets,
+repeat the last line of code for each of them. Accordingly,
+a loop becomes even more
+attractive.
-
-
Advanced CMakeLists.txt
+
If you only have a single file or few files with common source
+code, an alternative to creating a library might be the option:
-
- For large projects the simple CMakeLists.txt presented
- above tends to be too inflexible.
- So, if you wish to have more control about targets the
- DEAL_II_SETUP_TARGET macro might be of interest for you.
- Here is a full example, again using the step-1 tutorial program as a
- template:
-
+
+ADD_EXECUTABLE(mycode mycode.cc common.cc)
+DEAL_II_SETUP_TARGET(mycode)
- #
- # It is good practise to specify a version requirement:
- #
- CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
-
- #
- # Find and import the deal.II project configuration:
- #
- FIND_PACKAGE(deal.II 8.0 REQUIRED
- HINTS
- ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
- #
- # If the deal.II library cannot be found (because it is not installed at a
- # default location or your project resides at an uncommon place), you
- # can specify additional hints for search paths here, e.g.
- # "$ENV{HOME}/workspace/deal.II"
- #
- )
-
- #
- # Initialize cached variables: This will set the compiler and
- # compiler flags to the values deal.II was configured with, as well as,
- # CMAKE_BUILD_TYPE to "Debug".
- # These values can be altered by editing the cache via
- # $ make edit_cache
- #
- DEAL_II_INITIALIZE_CACHED_VARIABLES()
-
- #
- # PROJECT has to be called after DEAL_II_INITIALIZE_CACHED_VARIABLES
- # otherwise CMake will have already set the compiler and compiler
- # flags.
- #
- PROJECT(step-1)
-
- #
- # Specify a target:
- #
- ADD_EXECUTABLE(step-1 step-1.cc)
-
- #
- # DEAL_II_SETUP_TARGET will set up all necessary include paths,
- # preprocessor definitions and the link interface:
- #
- DEAL_II_SETUP_TARGET(step-1)
-
- #
- # (Optional)
- # If you wish to have a "run" target for make, specify one:
- #
- ADD_CUSTOM_TARGET(run
- COMMAND step-1
- COMMENT "Run ${TARGET} with ${CMAKE_BUILD_TYPE} configuration"
- )
-
You should be aware though that common.cc will be
+compiled for each target, not only once.
-
-
Advanced setup for deal.II in a CMake project
+
Matthias, is this correct?
-
-
Finding the deal.II library
+
+
Adding a "run" target
+
- Finding the deal.II library should be no more than
-
+ If you wish to have a "run" target for make, like in the deal.II
+ tutorial, specify one this way (obviously, a single "run" target
+ can only run a single executable):
+
+
+ADD_CUSTOM_TARGET(run COMMAND mycode
+ COMMENT "Run with ${CMAKE_BUILD_TYPE} configuration")
+
+
+
+
+
Advanced CMakeLists.txt
+
+
+
+ A Subsection for each of the following:
+
+ - control statements (if and foreach)
+
+ - file glob to pick up sources
+
+ - DEAL_II_SETUP_TARGET and DEAL_II_INITIALIZE_CACHED_VARIABLES
+ revisited
+
+ - add include dirs and compile definitions to a directory or target
+
+ - provide a ./run folder and target
+
+ - custom targets to switch between release and debug
+
+ - installation
+
+
+
+
Finding the deal.II library
+
+
+ Finding the deal.II library should be no more than
+
+
FIND_PACKAGE(deal.II REQUIRED)
-
- in your CMakeLists.txt file. You may have to hint for the location
- of the deal.IIConfig.cmake file. Either by directly
- specifying deal.II_DIR to point to the path were the
- deal.IIConfig.cmake file is located:
-
- or by specifying a search path via CMAKE_PREFIX_PATH,
- e.g.
-
-
+
+ in your CMakeLists.txt file. You may have to hint for the location
+ of the deal.IIConfig.cmake file. Either by directly
+ specifying deal.II_DIR to point to the path were the
+ deal.IIConfig.cmake file is located:
+
+
is deal.II_DIR still accurate? We use different
+above. BTW, that is an UGLY variable name.
+ If you want a make interface similar to the deal.II library and
+ its tutorial, namely maker targets for debug and release
+ versions, running the code and cleaning, the easiest way to
+ write a CMakeLists.txt file may be to use
+ an "autopilot" style macro. Here is a minimalistic example for the
+ step-1 tutorial program (plain text version) that can be used for simple
+ projects:
+
+
+
+FIND_PACKAGE(deal.II 8.0 REQUIRED
+ HINTS
+ ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
+ # You can specify additional hints for search paths here, e.g.
+ # $ENV{HOME}/workspace/deal.II
+)
+
+# Set the name of the project and target:
+SET(TARGET "step-1")
+
+# Declare all source files the target consists of:
+SET(TARGET_SRC
+ step-1.cc
+ # You can specify additional files here!
+)
+
+CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
+DEAL_II_INITIALIZE_CACHED_VARIABLES()
+PROJECT(${TARGET} CXX)
+DEAL_II_INVOKE_AUTOPILOT()
+
-
- Importing the deal.IIConfig.cmake file via FIND_PACKAGE
- will set a bunch of variables and macros; all of the form
- DEAL_II_*. There is the usual duplet:
-
-
- DEAL_II_INCLUDE_DIRS
- DEAL_II_LIBRARIES
-
- (with debug and optimized keywords. For
- compatibility there is also DEAL_II_LIBRARIES_DEBUG
- and DEAL_II_LIBRARIES_RELEASE only specifying the
- respective set of libraries.)
-
-
- For actually using deal.II in your CMake
- project some configuration steps are necessary. These can be
- either set via macros or by hand:
-
-
Configuration with the help of
- two convencience macros:
-
- deal.IIConfig.cmake includes some convenience macros
- to automatically setup all necessary configuration. A fully
- functional, minimal example for the step-1 tutorial program is:
-
-
- FIND_PACKAGE(deal.II REQUIRED)
+ This CMakeLists.txt is intended for use with a small
+ project and in-source build (i.e., one does not create a separate
+ build directory as we recommend for the deal.II build
+ in the readme
+ file). Using this input file, you can run cmake in the
+ source directory as follows:
- DEAL_II_INITIALIZE_CACHED_VARIABLES()
-
- PROJECT(step-1)
-
- ADD_EXECUTABLE(step-1 step-1.cc)
- DEAL_II_SETUP_TARGET(step-1)
-
-
-
-
-
Configuration by hand:
-
-
Set up all include directories for header files:
-
- deal.II usually ships with an optimized Release and a Debug version
- of the library. So it is a good idea to set up
- CMAKE_BUILD_TYPE accordingly:
-
-
- SET(CMAKE_BUILD_TYPE "Debug" CACHE
- "Choose the type of build, options are: Debug, Release"
- )
-
-
- A cached variable ensures that we can later switch the build type
- by editing the cache:
-
-
- make edit_cache
-
-
-
Often, it is a good idea to use the same compiler and linker
- flags as the deal.II library.
-
- (Optionally you can set up the variables with the
- CACHE to be able to edit them via ccmake or
- make edit_cache.)
-
-
- After this, specify your project name:
-
-
- PROJECT(myProject)
-
- This ensures that the compiler detection and platform setup
- that is issued by calling PROJECT(...) will run
- after we have set up our cached variables. This way it is
- our choice of variables that will be set and not the default
- values determined by the PROJECT(...) call.
-
-
- After defining your targets, e.g.
-
-
- ADD_EXECUTABLE(step-1 step-1.cc)
-
- you have to specify to link against deal.II and all external
- libraries:
-
- For an advanced setup in a big CMake project
- deal.IIConfig.cmake
- provides information about the deal.II
- installation with traditional variables, see
- here, as well as external CMake
- targets with link interface for direct inclusion:
-
+$ cd step-1
+$ cmake .
+
+[...]
+
+###
+#
+# Successfully set up project step-1 with deal.II-99.99.svn30300 found at
+# /usr
+#
+# CMAKE_BUILD_TYPE: Debug
+#
+# You can now run
+# $ make - to compile and link the program
+# $ make run - to (compile, link and) run the program
+#
+# $ make debug - to switch the build type to Debug
+# $ make release - to switch the build type to Release
+#
+# $ make edit_cache - to change (cached) configuration variables
+# and rerun the configure and generate phases of CMake
+#
+# $ make strip_comments - strip the source files in this
+# directory off the documentation comments
+# $ make clean - to remove the generated executable as well as
+# all intermediate compilation files
+# $ make runclean - to remove all output generated by the program
+# $ make distclean - to clean the directory from _all_ generated
+# files (includes clean, runclean and the removal
+# of the generated build system)
+#
+# $ make help - to view this message again
+#
+# Have a nice day!
+#
+###
+
+
+ There are two additional configuration options (in addition to
+ TARGET and TARGET_SRC) that can be set via
+ variables before DEAL_II_INVOKE_AUTOPILOT() is called
+ (plain text version):
+
+
+# (Optional)
+# Specify a list of files (file globs) that will be removed
+# with the "make runclean" and "make distclean" targets.
+# (If empty, sensible default values will be used.)
+SET(CLEAN_UP_FILES
+ # a custom list of globs, e.g. *.log *.vtk
+)
+
+# (Optional)
+# A custom command line that should be invoked by "make run".
+# (If empty, ./${TARGET} will be invoked.)
+SET(TARGET_RUN
+ # a custom command line, e.g. mpirun -np 2 ${TARGET}
+)
+
+
+
+
+
deal.IIConfig.cmake
+
+
+ Importing the deal.IIConfig.cmake file via FIND_PACKAGE
+ will set the following variables and macros; all of the form
+ DEAL_II_*:
+
+
+A long list with detailed explanation...
+
+
-
Legacy Make.global_options
+
Legacy Make.global_options
Before version 8.0, deal.II used the
diff --git a/deal.II/doc/development/toc.html b/deal.II/doc/development/toc.html
index a213bd675b..72d76a8232 100644
--- a/deal.II/doc/development/toc.html
+++ b/deal.II/doc/development/toc.html
@@ -41,7 +41,7 @@
This page provides extensive information about configuration and
installation with the CMake build system.
-
Using CMake and
deal.II in a user project:
This page covers how to use CMake in your own project.
An overview of how to retrieve necessary information
diff --git a/deal.II/doc/development/writing-documentation.html b/deal.II/doc/development/writing-documentation.html
index 4ab4d3e318..e9b037dffd 100644
--- a/deal.II/doc/development/writing-documentation.html
+++ b/deal.II/doc/development/writing-documentation.html
@@ -179,9 +179,9 @@
Typewriter font:
In order to use typewriter font for instance for function
- arguments or variables, use the <tt> HTML
+ arguments or variables, use the <code> HTML
tag. For a single word, you can also use the form @p
- one_word_without_spaces.
+ one_word_without_spaces. The <tt> is obsolete in HTML5
If you refer to member variables and member functions
diff --git a/deal.II/doc/documentation.html b/deal.II/doc/documentation.html
index 941beef63e..10620b4c56 100644
--- a/deal.II/doc/documentation.html
+++ b/deal.II/doc/documentation.html
@@ -2,208 +2,203 @@
"http://www.w3.org/TR/html4/loose.dtd">
- The tutorial is
- for new users of the library. It explains the basic elements of
- finite element programs based on the library, and provides small
- example programs. You can also reach the tutorial link from the menu bar
- at the left.
-
-
-
- Note that along with the rest of the documentation, the local HTML pages
- of the tutorials need to be generated first. Please follow the
- instructions in the
- ReadMe file on how to do
- this.
-
- The programming
- interface/manual pages are what you will need most often as a
- reference of all classes, functions and variables in the library. They
- are extensively documented (presently more than 5000 pages if
- printed), and generated by Doxygen. There is also a quick link to these pages from
- the menu bar at the left.
-
-
-
- The documentation uses many of the features of Doxygen. In particular,
- the link takes you straight to a page that lists modules, a way
- to group classes with similar purposes. This may be what you are probably
- interested in when you are not yet familiar with the library. If you
- already know your way around and want to look up the signature of a
- particular member function, for example, you may go to the class view or
- choose any of the other ways in which Doxygen allows you to navigate
- through the documentation.
-
-
-
- Just as for the tutorials, the API docs need to be generated first,
- if you download deal.II. Please follow the
- instructions in the
- ReadMe file on how to do
- this.
-
- There are a number of papers that describe the overall design or
- individual aspects of deal.II. Please refer to the
- papers listed at the top of the publications page for full references. In addition,
- there are the following reports:
-
-
- A publication on the
- basics of dimension independent
- programming in deal.II (by Wolfgang
- Bangerth). This explains some of the fundamentals of the
- library's design, though rather briefly due to the page
- limit imposed for the publication.
-
-
-
- This publication appeared in
- the proceedings of the 16th IMACS World Congress,
- Lausanne, Switzerland, 2000. See the
- publications
- page for the full reference as well as a way to obtain a
- reprint of the original paper as a postscript or PDF file.
-
-
-
- A brief report about the classes involved in the
- iterators and accessors
- used to access cells in the triangulations and the data
- thereon, such as their geometry, the number of the
- degrees of freedom, data values, etc. You may want to
- read this object or parts of it if you want to know what
- information is available from iterators (by Wolfgang
- Bangerth).
-
-
-
- A brief report on mapping functions of higher polynomial
- degrees (by Ralf Hartmann). These allow the realisation
- of higher order boundary approximations. This report
- gives the theoretical background of the
- MappingQ class.
-
-
-
- A report on
- assembling matrices (by Wolfgang
- Bangerth). This report looks in particular at how
- matrices are assembled for vector-valued problems, and
- how things change if vector-valued finite elements are
- used for which the shape functions have more than one
- non-zero vector component, such as Nedelec or
- Raviart-Thomas elements. There are printable
- versions of the report
- in postscript and
- PDF format.
-
-
-
- A very detailed report on
- Nedelec elements (by Anna
- Schneebeli, University of Basel, Switzerland). It
- explains the construction and application of Nedelec
- edge elements for H-curl spaces, as used, for example,
- in the numerical solution of the Maxwell equations. It
- also gives numerical results obtained with deal.II.
- There is also a postscript version of the report.
-
-
-
- A report on the
- codimension one capabilities
- of the library (by Antonio DeSimone, Luca Heltai
- and Cataldo Manigrasso, SISSA, Trieste, Italy). It
- explains in detail how to use the
- library for the solution of problems defined on codimension
- one manifolds, such as, for example, Boundary Element Methods.
-
+ The tutorial is
+ for new users of the library. It explains the basic elements of
+ finite element programs based on the library, and provides small
+ example programs. You can also reach the tutorial link from the menu bar
+ at the left.
+
+
+
+ Note that along with the rest of the documentation, the local HTML pages
+ of the tutorials need to be generated first. Please follow the
+ instructions in the
+ ReadMe file on how to do
+ this.
+
+ The programming
+ interface/manual pages are what you will need most often as a
+ reference of all classes, functions and variables in the library. They
+ are extensively documented (presently more than 5000 pages if
+ printed), and generated by Doxygen. There is also a quick link to these pages from
+ the menu bar at the left.
+
+
+
+ The documentation uses many of the features of Doxygen. In particular,
+ the link takes you straight to a page that lists modules, a way
+ to group classes with similar purposes. This may be what you are probably
+ interested in when you are not yet familiar with the library. If you
+ already know your way around and want to look up the signature of a
+ particular member function, for example, you may go to the class view or
+ choose any of the other ways in which Doxygen allows you to navigate
+ through the documentation.
+
+
+
+ Just as for the tutorials, the API docs need to be generated first,
+ if you download deal.II. Please follow the
+ instructions in the
+ ReadMe file on how to do
+ this.
+
+ There are a number of papers that describe the overall design or
+ individual aspects of deal.II. Please refer to the
+ papers listed at the top of the publications page for full references. In addition,
+ there are the following reports:
+
+
+
+ A publication on the
+ basics of dimension independent
+ programming in deal.II (by Wolfgang
+ Bangerth). This explains some of the fundamentals of the
+ library's design, though rather briefly due to the page
+ limit imposed for the publication.
+
+
+
+ This publication appeared in
+ the proceedings of the 16th IMACS World Congress,
+ Lausanne, Switzerland, 2000. See the
+ publications
+ page for the full reference as well as a way to obtain a
+ reprint of the original paper as a postscript or PDF file.
+
+
+
+
+ A brief report about the classes involved in the
+ iterators and accessors
+ used to access cells in the triangulations and the data
+ thereon, such as their geometry, the number of the
+ degrees of freedom, data values, etc. You may want to
+ read this object or parts of it if you want to know what
+ information is available from iterators (by Wolfgang
+ Bangerth).
+
+
+
+ A brief report on mapping functions of higher polynomial
+ degrees (by Ralf Hartmann). These allow the realisation
+ of higher order boundary approximations. This report
+ gives the theoretical background of the
+ MappingQ class.
+
+
+
+ A report on
+ assembling matrices (by Wolfgang
+ Bangerth). This report looks in particular at how
+ matrices are assembled for vector-valued problems, and
+ how things change if vector-valued finite elements are
+ used for which the shape functions have more than one
+ non-zero vector component, such as Nedelec or
+ Raviart-Thomas elements. There are printable
+ versions of the report
+ in postscript and
+ PDF format.
+
+
+
+ A very detailed report on
+ Nedelec elements (by Anna
+ Schneebeli, University of Basel, Switzerland). It
+ explains the construction and application of Nedelec
+ edge elements for H-curl spaces, as used, for example,
+ in the numerical solution of the Maxwell equations. It
+ also gives numerical results obtained with deal.II.
+ There is also a postscript version of the report.
+
+
+
+ A report on the
+ codimension one capabilities of the library
+ (by Antonio DeSimone, Luca Heltai and Cataldo Manigrasso,
+ SISSA, Trieste, Italy). It explains in detail how to use the
+ library for the solution of problems defined on codimension
+ one manifolds, such as, for example, Boundary Element
+ Methods.
+
deal.II is copyright of the
- deal.II authors.
- It is a joint effort of the current maintainers, Wolfgang
- Bangerth, Timo Heister, Guido Kanschat, and quite a number of
- contributors. deal.II is distributed under an
+
+
+
+ deal.II is copyright of the
+ deal.II authors. It is
+ a joint effort of the current maintainers, Wolfgang Bangerth,
+ Timo Heister, Guido Kanschat, and quite a number of
+ contributors. deal.II is distributed under
+ an
OpenSource
license. The full text of the license can be found in
license.html.
-
Contact
+
Contact
We have a discussion group for discussion
of issues of general interest to users and developers of
deal.II.
-
+
More specific questions may be sent to the authors
immediately at the address firstName.lastname at
dealii.org.
- deal.II is mostly developed on Linux using the
- GCC compiler. However, it is not
- platform specific and we strive to keep the source code C++
- Standard compliant.
-
-
-
- deal.II supports at least the following
- platforms:
-
-
GNU/Linux: GCC version 4.0 or later;
- Clang version 3.0 or later; ICC version 12 or later
-
Mac OS X: GCC version 4.0 or later; Clang version 3.0 or later
- (Please see the deal.II Wiki for installation issues)
-
+ deal.II is mostly developed on Linux using the
+ GCC compiler. However, it is not
+ platform specific and we strive to keep the source code C++ Standard
+ compliant.
+
+
+
+ deal.II supports at least the following
+ platforms:
+
+
+
GNU/Linux: GCC version 4.0 or later;
+ Clang version 3.0 or later; ICC version 12 or later
+
Mac OS X: GCC version 4.0 or later; Clang version 3.0 or later
+ (Please see the deal.II Wiki for installation issues)
+
Windows: Cygwin with recent GCC or Clang versions.
+ Native Windows support with recent
+ MinGW compiler.
+ For installing on Windows, please refer to
+ additional information on the deal.II Wiki and have a look at the bug
- tracker!
-
- Most other combinations of POSIX-style operating systems and C++
- Standard compliant compilers should also work. If they don't,
- please report it as a bug.
-
+ tracker!
+
+
+ Most other combinations of POSIX-style operating systems and C++
+ Standard compliant compilers should also work. If they don't,
+ please report it as a bug.
+
-
- Please note that the Microsoft Visual C++ compiler, that is widely
- used on Microsoft Windows, is not supported. If you need a native
- Windows target, use the MinGW compiler instead.
-
+
+ Please note that the Microsoft Visual C++ compiler, that is widely
+ used on Microsoft Windows, is not supported. If you need a native
+ Windows target, use the MinGW compiler instead.
+
-
-
Additional software requirements
+
+
Additional software requirements
In order to compile and use deal.II
you need to have the following programs installed:
+ GNU make, version
+ 3.78 or later (or any other generator supported by CMake)
+
-
- For generating the documentation:
- Perl 5.x,
- doxygen
- and dot, which is part of the
- GraphViz
- package
-
+
+ For generating the documentation:
+ Perl 5.x,
+ doxygen
+ and dot, which is part of the
+ GraphViz
+ package
+
-
+
For debugging programs, we have found that the
GNU
debugger GDB is an invaluable tool. GDB is a text-based tool
@@ -142,21 +143,22 @@
like kdevelop
or Eclipse have built
in debuggers as well.
-
+
gnuplot
and a postscript viewer (for eps) should be
@@ -179,37 +181,35 @@
converted into output (without references to cells, nodes,
types of finite elements, and the like).
+
-
-
-
-
+
Installation
-
-
+
+
Unpacking
The whole library usually comes as a tar.gz file,
which is a file archive compressed with gzip. After downloading it,
unpack it using either
-
-
- gunzip deal.II-X.Y.Z.tar.gz
- tar xf deal.II-X.Y.Z.tar
-
- or, if you have GNU tar with
-
-
- tar -xvf deal.II-X.Y.Z.tar.gz
-
- Note: You will want to hang on to the source files
- of deal.II after installation as it makes developing
- much simpler. Consequently, you should do the steps above in a permanent
- directory, not on /tmp as one often does when installing
- software.
+
+ gunzip deal.II-X.Y.Z.tar.gz
+ tar xf deal.II-X.Y.Z.tar
+
+
or, if you have GNU tar with
+
+ tar -xvf deal.II-X.Y.Z.tar.gz
+
+
+
Note: You will want to hang on to the source files
+ of deal.II after installation as it makes
+ developing much simpler. Consequently, you should do the steps above
+ in a permanent directory, not on /tmp as one often does
+ when installing software.
+
Configuring and building the library
@@ -219,21 +219,23 @@
CMake
integrated configuration and build system. Unpacking will create a
subdirectory deal.II/ in the current directory. Then do the
- following steps:
-
-
- mkdir build
- cd build
- cmake -DCMAKE_INSTALL_PREFIX=/path/to/install/dir ../deal.II
- make install
-
- These steps compile, link and install the deal.II library. The
- whole process should take between a few minutes and an hour, depending
- on your machine.
-
+ following steps:
+
+
+ mkdir build
+ cd build
+ cmake -DCMAKE_INSTALL_PREFIX=/path/to/install/dir ../deal.II
+ make install
+
+
+
+ These steps compile, link and install the deal.II library. The
+ whole process should take between a few minutes and an hour, depending
+ on your machine.
+
- Note:
+ Note:
/path/to/install/dir is the directory which deal.II
should be installed into. This can be a directory in your home
@@ -242,6 +244,7 @@
Another option is to use something like `pwd`/../installed/ (note the
backticks). Make sure the installation directory is not the same
as the location where you unpacked deal.II/.
+
If your machine has multiple processors, use make
-jN in the last step, where N is the
@@ -249,10 +252,12 @@
to use at any given time. Allowing make to use
more simultaneous build processes (assuming you have that many
processor cores) will greatly lower the build time.
+
If you do not intend to modify the deal.II
sources and recompile things, then you can remove
the build/ directory after the last step.
+
In principle, after installing deal.II, you
can remove the source directory as well (i.e., the directory into
@@ -262,10 +267,12 @@
files around anyway, for one reason: When
debugging you often end up with assertions for which you'd like to
see the place in the library's source files that triggered it.
+
The deal.II CMake system can accept a
significant number of configuration parameters. See the
discussion below.
+
If you are changing part of the deal.II
code itself, you can re-compile the library using only the
@@ -276,41 +283,41 @@
However, this sometimes leads to surprising results and you may
not get exactly what you were hoping for. For more information,
see here.
-
+
-
The commands above build and install the deal.II
libraries in two variants:
-
-
-
Debug mode: This version of the
- library is compiled with compiler flags so
- that the library contains information that can be used by debuggers.
-
-
-
- In addition, this library contains a great number of safety
- checks on most arguments of all functions you could possibly call.
- These assertions have proven to be an
- invaluable means to finding programming bugs since they will
- almost always abort your program if something goes wrong. In our
- experience, more than ninety per cent of all errors are invalid
- parameters (such as vectors having the wrong size, etc.) and they
- are usually found almost instantaneously, displaying the file
- name and line number of where the problem occurred.
-
-
+
+
+
+
Debug mode: This version of the
+ library is compiled with compiler flags so
+ that the library contains information that can be used by debuggers.
+
+
+
+ In addition, this library contains a great number of safety
+ checks on most arguments of all functions you could possibly call.
+ These assertions have proven to be an
+ invaluable means to finding programming bugs since they will
+ almost always abort your program if something goes wrong. In our
+ experience, more than ninety per cent of all errors are invalid
+ parameters (such as vectors having the wrong size, etc.) and they
+ are usually found almost instantaneously, displaying the file
+ name and line number of where the problem occurred.
+
+
+
Optimized mode: You will want to link with this version of
the library once you know that your program is working as
expected. It does not contain the safety checks any more
and is compiled with aggressive compiler optimizations. The
resulting executables are smaller and will run between 2 and 10
times faster than the debug executables.
-
+
-
At this point, you have generated everything necessary to write
@@ -327,17 +334,20 @@
be found at the
http://www.dealii.org/ domain can also be generated locally. To do
so, invoke cmake in the build instructions above as follows:
-
@@ -388,6 +398,7 @@
threading off by passing the -DDEAL_II_WITH_THREADS=OFF
argument to cmake.
+
@@ -399,6 +410,7 @@
specifically do not want to use it, then
pass -DDEAL_II_WITH_MPI=OFF.
+
@@ -416,6 +428,7 @@
-DDEAL_II_COMPONENT_PARAMETER_GUI=ON. Beware of the
fact that parameter_gui needs development packages for Qt.
+
@@ -433,12 +446,12 @@
with Trilinos, Trilinos 11.2 or later is needed (there is a bug in
Trilinos 11.0 that prevents the use of 64bit indices).
-
+
-
+
Optional interfaces to other software packages
@@ -460,8 +473,7 @@
can be configured.
-
- Notes:
+
Notes:
The majority of libraries mentioned below should be readily
@@ -470,6 +482,7 @@
e.g. ending in -dev or -devel.
After that cmake will automatically find the
library and use it.
+
Configuring the interface to a self compiled package,
say foo can usually be done by specifying
@@ -480,17 +493,18 @@
you invoke cmake in a fresh build directory.
Any value passed on the command line wins over a value that
may be found in an environment variable.
+
To explicitly enable or disable support for
a library foo use the argument
-DDEAL_II_WITH_FOO=ON resp.
-DDEAL_II_WITH_FOO=OFF for cmake.
+
- NetCDF is a library that provides services for
- reading and writing mesh data (and many other
- things). deal.II can use it to read meshes via
- one of the functions of the GridIn class.
- NetCDF should be readily packaged by most
- Linux distributions. (Don't forget to install a development
- version of the library). To use a self compiled version, pass
- -DNETCDF_DIR=/path/to/netcdf to cmake.
+ NetCDF is a library that provides services for
+ reading and writing mesh data (and many other
+ things). deal.II can use it to read meshes via
+ one of the functions of the GridIn class.
+ NetCDF should be readily packaged by most
+ Linux distributions. (Don't forget to install a development
+ version of the library). To use a self compiled version, pass
+ -DNETCDF_DIR=/path/to/netcdf to cmake.
More information on configuring and building the library
@@ -821,27 +836,31 @@
information.
- Please note:
+ Please note:
Detailed license information can be found following
this link.
+
As a contributor to this project, you agree that any of your
contributions be licensed under the same terms and conditions as
the license of the deal.II project granted to you.
+
We, the deal.II authors, do not require
copyright assignments for contributions. This means that the
copyright for code contributions in the deal.II project is held by
its respective contributors who have each agreed to release their
contributed code under the terms of the LGPL v2.1 or later.
+
In addition to the terms imposed by the LGPL (version 2.1 or
later), we ask for the courtesy that scientific publications
presenting results obtained with this libraries acknowledge its
use. Please cite one of the papers referenced
here.
+
deal.II can interface with a number of other packages that you either
@@ -856,13 +875,21 @@
target="_top">FunctionParser, courtesy of their authors.
These are also covered by their own licenses; please refer to
their webpages for more information.
+