<title>Porting deal.II</title>
<link href="screen.css" rel="StyleSheet" media="screen">
<meta name="author" content="the deal.II authors <authors@dealii.org>">
- <meta name="copyright" content="Copyright (C) 2000, 2001, 2002, 2005 by the deal.II authors">
+ <meta name="copyright" content="Copyright (C) 2000, 2001, 2002, 2005, 2010 by the deal.II authors">
<meta name="date" content="$Date$">
<meta name="svn_id" content="$Id$">
<meta name="keywords" content="deal.II porting">
<h1>Porting <acronym>deal.II</acronym> to new systems</h1>
<p>
- Since <acronym>deal.II</acronym> uses very few system dependent
- features, there is a good chance that it might also run on other
- systems besides the one listed in the
+ <acronym>deal.II</acronym> 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
<a href="readme.html" targte="body">ReadMe file</a>. Nevertheless,
- there are often cases where some adjustments are necessary. We will
- try to give you an impression on what might have to be done in such
- cases here.
+ there are cases where some adjustments are necessary.
</p>
<p>
Basically, all the setup of the specifics or a system is done in the
- ``configure'' script that is run first. This script finds out about
+ <code>./configure</code> 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.
- </p>
-
- <p>
- ``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
+ <code>./configure</code> is not made for human eyes. It is in fact only a
+ script generated by the <code>autoconf</code> program from the files
+ <code>configure.in</code> and <code>aclocal.m4</code> in the top-level directory of
<acronym>deal.II</acronym>. 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).
+ <code>configure.in</code> (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 <code>autoconf</code>
</p>
<p>
- When the ``configure'' script is run on the shell, it writes its
- results into the file ``common/Make.global_options'' that contains
- definitions of all compiler flags to be used, as well as paths to
- programs and other options. In fact, ``configure'' rather takes the
- file ``common/Make.global_options.in'' and replaces all occurences
- of variables ``@var@'' by the value of the respective variable in
- the ``configure'' shell script.
+ At the end of running <code>./configure</code>, it creates output files by
+ replacing all occurrences of variables like <code>@var@</code> in input files
+ by the value of the respective environment variable in
+ the <code>configure</code> shell script. By convention, input files have a
+ file ending <code>.in</code>; the two most important input/output file pairs
+ are <code>common/Make.global_options</code>
+ and <code>common/Make.global_options.in</code> as well as
+ <code>include/deal.II/base/config.h.in</code>
+ and <code>include/deal.II/base/config.h</code>.
</p>
<p>
If you find something that does not work on your system, then the
quickest way to make <acronym>deal.II</acronym> run on your system
- is to run ``configure'' and change things in
- ``common/Make.global_options'' so that it works for you. Note that
- this file is overwritten next time you run ``configure''.
+ is to run <code>configure</code> and change things in
+ <code>common/Make.global_options</code> by hand so that it works for
+ you. The downside is that
+ this file is overwritten next time you run <code>./configure</code>.
</p>
<p>
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
- ``common/Make.global_options'', e.g. by setting the variable
- ``enable-shared'' to ``no'', or by changing the compiler flags in
- the variables ``CXXFLAGSG'' (for debug mode) or ``CXXFLAGSO'' (for
- optimized mode).
+ <code>common/Make.global_options</code>, e.g. by setting the variable
+ <code>enable-shared</code> to <code>no</code>, or by changing the compiler flags in
+ the variables <code>CXXFLAGS.g</code> (for debug mode) or <code>CXXFLAGS.o</code> (for
+ optimized mode). The most important variables in
+ <code>common/Make.global_options</code> are
+ <a href="development/makefiles.html">listed here</a>.
</p>
<li>
<p>
- If you know the basics of ``autoconf'', or of shell scripting, you
+ If you know the basics of <code>autoconf</code>, or of shell scripting, you
will be able to write tests for the changes that are necessary in
- ``configure.in'' yourself. There are plenty of examples, both for
+ <code>configure.in</code> or <code>aclocal.m4</code> 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
+ <code>DEAL_II_CHECK_ASSERT_THROW</code> in <code>aclocal.m4</code> that shows how to
+ test whether the <code>AssertThrow</code> construct in
<acronym>deal.II</acronym> works as intended (this check is
- necessary since some compiler versions get an internal compiler
+ necessary since some very old compiler versions get an internal compiler
error on DEC Alpha machines for this construct).
</p>
<p>
- 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
+ If you have made such changes to <code>configure.in</code> or
+ <code>aclocal.m4</code>, run <code>autoconf</code> in the top-level directory to
+ regenerate the <code>configure</code> script, which you should then run and
+ see whether the output in <code>common/Make.global_options</code> matches
your expectations.
</p>
on your system, or if you don't have the expertise to dig into the
low-level parts of your system, and if you can provide a test
account, you may ask us to try to get things running on your
- machine. Please note that <em>we can't promise to do that as this is
+ machine. Please note that <em>we can't promise to do that as <acronym>deal.II</acronym> is
largely a volunteer project and we can only do it if time
permits!</em> Nevertheless, we have an interest to have the library
running on as many platforms as possible, so the odds are not that