If support for OpenMP should be added, it must be specified by
setting an option. If not, then warnings for unknown pragmas are
disabled, so that the code can have #pragma omp witout getting
messages during build.
If the directory that is specified does not exist, then keep the path
as entered, which makes for better error messages later.
We cannot print an warning on a non-existent name, because it may be
target directories that are specified, or perhaps logical options
(like --with-mpi=yes)
Traditionally, options are put before any other command-line arguments.
However, dunecontrol puts variable assignment before options, like env,
and this confuses getopt.
This variant (based on a suggestion by Andreas Lauser) collects the
variables into an array at the same time as the options are processed.
Follow the guidelines in
<http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/
html_node/Option-Checking.html#Option-Checking>
and print a *warning* if there is an unknown --enable-* or --with-*
option, error otherwise. --disable-option-checking does not turn off the
errors, but silences the warnings.
If we are going to set e.g. CXXFLAGS to more than one value, the
quotes must be preserved at the same time as the list is laundered
(for autotools-variables)
dunecontrol will specify --with-* for each and every module that is
listed as a dependency in dune.module; there is no difference between
them because they all share the same code :-)
If you are using a custom CMake, you should be able to set the
environment variable "CMAKE" and have the configure script pick up
the default from there so that you don't have to specify the option
every time.
Having option checking catches typos. Disabling the checking enable us
to use the same build options for a bunch of packages even though they
may not have the same dependencies.
dunecontrol should be passed the option
--configure-opts="--enable-fieldvector-size-is-method" if you want to
rebuild it from scratch without bazillion strange deprecation warnings,
this flag allows us to participate in that dance.
If the installation prefix is set to /usr, then it is assumed that the
user has write access to the entire of that subtree, and that it would
be advantageous to put the .debug files in the /usr/lib/debug directory.
This is the usual case for package installations.
On the other hand, if the prefix is NOT /usr, then it is probably a
local installation; someone trying to install it to a more restricted
area. In that case, the default is to follow the binary, so that GDB
will still pick up the .debug file when loading the shared object.
In any case can this default be overridden, should it turn out that the
configuration script has guessed wrongly for your needs.
Some versions of the compiler are buggy, and will actually crash if
precompiled headers are used. This option enable disabling the feature
and building without by simply setting a command-line option.
Use --prefix= in ./configure to enter the directory under which the
files should be installed on the target system, use DESTDIR= in
make install to redirect files to another location when building.
By using --disable-debug (--enable-debug is the default), release mode
can be toggled from the wrapper script.
Some IDEs, notably QtCreator requires this flag to be set when running
CMake, in order to enable debugging properly. Thus, it is explicitly
set (and printed) when using ./configure also.
Old implementation had a problem with the special case that you
specified a directory directly under the root (e.g. /usr); dirname
adds a trailing slash in that case.
Since this is a compatibility script it will probably benefit people
seeing which underlaying CMake command is being executed (not at least
for debugging purposes)
Path to DUNE libraries are specified with the ROOT prefix, but with the
stem with the same name as the module -- in lowercase (otherwise; does
the hyphen uppercase to underscore?). This deviates somewhat from the
usual CMake convention of using uppercase all over the place.
Default is still to make a shared object because this is the most
versatile target (it can be included in other shared objects as well
as executables).
Note that due to limitations in CMake, either a shared or a static
library can be built, but not both. (This is due to the fact that on
Windows, an import library has the same name as a static library).
CMake will change to the source directory when processing the
CMakeLists.txt file which causes relative paths to be based on this
instead of at the build directory which is probably assumed by the
user.
Instead of having to run `ccmake` or looking up which variables that
must be set, the configure driver is now enhanced to recognize options
that sets the installation directories for some of the dependencies.
This script enables the use of `configure && make && make install` for
those users who have this combination ingrained in their fingers or are
too busy to read the manual.
