From: maier
- deal.II uses very few system dependent
- features. Consequently, there is a good chance that it might also run on other
- systems besides the ones listed in the
- ReadMe file. Nevertheless,
- there are cases where some adjustments are necessary.
-
- Basically, all the setup of the specifics or a system is done in the
-
- At the end of running
- If you find something that does not work on your system, then the
- quickest way to make deal.II run on your system
- is to run
- Most often, problems on new systems are caused by the compiler not
- accepting certain flags, crashing or producing invalid code on
- optimization flags, not supporting shared libraries, and the like.
- All these problems can be solved by changing
- Porting deal.II to new systems
./configure
script that is run first. This script finds out about
- operating system, processor, and the like, and then goes on testing
- whether certain features are present, or if their absence can be
- worked around.
- ./configure
is not made for human eyes. It is in fact only a
- script generated by the autoconf
program from the files
- configure.in
and aclocal.m4
in the top-level directory of
- deal.II. The first contains the order in which
- macros are called that test for features, interspersed by shell
- script snippets that do actions depending on the results of the
- macros. The second file contains the user-defined macros used in
- configure.in
(most macros are already predefined by autoconf).
- To understand how all this works together, you will have to have some, though
- not a whole lot of,
- knowledge of both Unix shell scripting as well as of autoconf
- ./configure
, it creates output files by
- replacing all occurrences of variables like @var@
in input files
- by the value of the respective environment variable in
- the configure
shell script. By convention, input files have a
- file ending .in
; the two most important input/output file pairs
- are common/Make.global_options
- and common/Make.global_options.in
as well as
- include/deal.II/base/config.h.in
- and include/deal.II/base/config.h
.
+ Consequently, there is a good chance that deal.II
+ will run on a reasonably well behaved system besides the ones listed
+ in the ReadMe. Nevertheless,
+ there are cases where some adjustments are necessary.
Quick porting
+ Unknown compiler
configure
and change things in
- common/Make.global_options
by hand so that it works for
- you. The downside is that
- this file is overwritten next time you run ./configure
.
- common/Make.global_options
, e.g. by setting the variable
- enable-shared
to no
, or by changing the compiler flags in
- the variables CXXFLAGS.g
(for debug mode) or CXXFLAGS.o
(for
- optimized mode). The most important variables in
- common/Make.global_options
are
- listed here.
+ Currently, the deal.II CMake Buildsystem
+ recognizes
+ gcc,
+ clang, as well as
+ icc, and
+ sets up reasonable default compiler flags.
+
+
-DDEAL_II_SETUP_DEFAULT_COMPILER_FLAGS=OFF
and set all
+ necessary compiler flags by hand via
+
+
+ CMAKE_CXX_FLAGS - used during all builds
+ DEAL_II_CXX_FLAGS_DEBUG - additional flags for the debug library
+ DEAL_II_CXX_FLAGS_RELEASE - additional flags for the release library
+
+ After that try to compile the library with minimal external
+ dependencies (-DDEAL_II_ALLOW_AUTODETECTION=OFF
, for
+ further information see the deal.II CMake
+ documentation).
+
+
+ cmake/setup_compiler_flags.cmake
+ cmake/setup_compiler_flags_gnu.cmake
+ cmake/setup_compiler_flags_icc.cmake
+
+ Patches are highly welcome! See here
+ for information on how to get in contact with us.
+
+
+ cmake/checks/check_for_compiler_bugs.cmake
+ cmake/checks/check_for_compiler_features.cmake
+ cmake/checks/check_for_cxx_features.cmake
+ include/deal.II/base/config.h.in
+
+ to see how compiler specific checks are done.
+
- While the measures shown above make deal.II run - on your system, it does not help other users. Neither does it mean - that the next version will run on your system unless you do the same - changes over again. There are basically two ways to help us make - deal.II run on your system by default: + deal.II should support almost all reasonably + POSIX compliant + platforms out of the box. Nevertheless, the following bits of + information might help:
source/base/timer.cc
have implementations for POSIX
+ and Windows and throw a compile time error on other platforms.
+ + + cmake/checks/check_for_compiler_bugs.cmake + cmake/checks/check_for_compiler_features.cmake + cmake/checks/check_for_cxx_features.cmake + cmake/checks/check_for_system_features.cmake + include/deal.II/base/config.h.in ++ to see how platform and compiler specific checks are done.
- You can send us the changes you had to make so that we can include - it into the distribution. -
- -
- If you know the basics of autoconf
, or of shell scripting, you
- will be able to write tests for the changes that are necessary in
- configure.in
or aclocal.m4
yourself. There are plenty of examples, both for
- things that we do depending on the system (for example disabling
- shared libraries on certain systems) or depending on the compiler
- (for example using some optimization flags for newer gcc
- versions), and depending on the results of feature tests. For the
- latter, you may for example take a look at the macro
- DEAL_II_CHECK_ASSERT_THROW
in aclocal.m4
that shows how to
- test whether the AssertThrow
construct in
- deal.II works as intended (this check is
- necessary since some very old compiler versions get an internal compiler
- error on DEC Alpha machines for this construct).
-
- If you have made such changes to configure.in
or
- aclocal.m4
, run autoconf
in the top-level directory to
- regenerate the configure
script, which you should then run and
- see whether the output in common/Make.global_options
matches
- your expectations.
-
- Of course, we would be happy to hear about the changes you made - for your system, so that we can include them into the next version - of the library. -
+ Of course, we would be happy to hear about the changes you made + for your system, so that we can include them into the next version + of the library!+ It is possible to use CMake to cross compile + deal.II for a foreign platform. Further + information on that topic can be found int the CMake + wiki.
Porting deal.II to a new system: - deal.II uses the mechanism provided by - GNU autoconf. Therefore, porting to a reasonably - standardized UNIX system should not be too difficult. Other - systems, such as proprietary ones, might or might not work (it is - possible, for example, to use Microsoft Windows); - see the ReadMe - file for more information on supported systems and porting. + + deal.II uses CMake as build system + and is fairly ISO (1998) C++ Standard compliant. + So, porting to a reasonably POSIX compliant + system with a reasonably ISO C++ compliant compiler shouldn't be + much work. Other (mostly proprietary) systems might require more + work. See the ReadMe + file for more information on already supported systems. This + resource gives some hints for porting to unknown platforms.
Bugs: