Since deal.II 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 ReadMe file. 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.
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.
``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).
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.
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 ``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''.
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).
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:
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'' 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 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.
If for some reason you cannot get deal.II 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 we can't promise to do that as this is largely a volunteer project and we can only do it if time permits! 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.