<commit_before><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
   "http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
  <head>
    <link href="screen.css" rel="StyleSheet" title="deal.II Homepage" media="screen">
    <link href="print.css" rel="StyleSheet" title="deal.II Homepage" media="print">
    <title>Porting deal.II</title>
    <meta name="author" content="<NAME>">
    <meta name="keywords" content="deal.II porting">
  </head>

  <body>
<h1>Porting <acronym>deal.II</acronym> to new systems</h1>

<p> Attention: before starting a port to a new system, check
the <a href="readme.html">readme file</a> for your system.</p>

<h2>Compiler flags</h2>

A configuration by setting the <TT>CXXFLAGS</TT> variable will soon be
supported.

<h2>Configuration file</h2>

<p>Configurations must be done in the file <TT>configure.in</TT> of
the root directory of <acronym>deal.II</acronym>. At the end, look for
a section of the structure
<pre>
case "$target" in
   *-linux*) ...;;
   *-aix*) ...;;
esac

case "$target" in
   alpha*-linux*) ...;;
esac
</pre>
The first case block allows you to adjust parameters for a certain
operating system, the second for an operating system/machine
configuration.</p>

<h3>Enable/disable configured options</h3>

<p>Some of the features of the library are turned on and off by
<TT>--enable-xxx</TT> and <TT>--with-xxx=yyy</TT> options to
configure. These user-supplied parameters can be changed by modifying
related variables: for example, to turn off shared libraries on aix,
enter the following in the operating system case-block
<pre>
   *-aix*) enableshared=no ;;
</pre>




<hr>
    
<address>
<a href="mailto:<EMAIL>">The deal.II
mailing list</a>
</address>

</body>
</html><commit_msg>Entirely rewrite the porting page.<commit_after><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
   "http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
  <head>
    <link href="screen.css" rel="StyleSheet" title="deal.II Homepage" media="screen">
    <link href="print.css" rel="StyleSheet" title="deal.II Homepage" media="print">
    <title>Porting deal.II</title>
    <meta name="author" content="<NAME>">
    <meta name="keywords" content="deal.II porting">
  </head>

  <body>


  <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 
  <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.
  </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
  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
  <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).
  </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.
  </p>



  <h2>Quick porting</h2>

  <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''.
  </p>

  <p>
  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
  ``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).
  </p>



  <h2>Portable porting</h2>

  <p>
  While the measures shown above make <acronym>deal.II</acronym> 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
  <acronym>deal.II</acronym> run on your system by default:
  <ul>
    <li>
    <p>
    You can send us the changes you had to make so that we can include
    it into the distribution.
    </p>

    <li>
    <p>
    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'' 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
    <acronym>deal.II</acronym> works as intended (this check is
    necessary since some 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
    your expectations.
    </p>

    <p>
    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.
    </p>
  </ul>
  </p>  


  <h2>Cheap porting</h2>

  <p>
  If for some reason you cannot get <acronym>deal.II</acronym> to run
  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
  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
  bad that we will find some spare time.
  </p>



<hr>
    
<address>
<a href="mailto:<EMAIL>.de">The deal.II
mailing list</a>
</address>

</body>
</html>
{'fraction_non_alphanumeric': 0.10243312273154993, 'fraction_numerical': 0.004167226777792714, 'mean_word_length': 3.62111801242236, 'pattern_counts': {'":': 0, '<': 130, '<?xml version=': 0, '>': 130, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5252200', 'n_tokens_mistral': 2322, 'n_tokens_neox': 2240, 'n_words': 1004}