mirror of https://gitlab.com/QEF/q-e.git
331 lines
10 KiB
Plaintext
331 lines
10 KiB
Plaintext
----------------------------------------------------------------------
|
|
HOW TO EDIT THE "configure" SCRIPT
|
|
----------------------------------------------------------------------
|
|
|
|
The "configure" script is generated from its source file
|
|
"configure.ac" by the GNU Autoconf utility
|
|
(http://www.gnu.org/software/autoconf/). Don't edit "configure"
|
|
directly: whenever it gets regenerated, your changes will be lost.
|
|
Instead, edit "configure.ac", then run "autoconf" to regenerate
|
|
"configure". (If you want to keep the old "configure", make a copy
|
|
first.)
|
|
|
|
GNU Autoconf is installed by default on most Unix/Linux systems. If
|
|
you don't have it on your system, you'll have to install it. Also, if
|
|
it bumps an error message saying "configure.in not found", you'll have
|
|
to install a more recent version. Version 2.53 at least is known to
|
|
work.
|
|
|
|
"configure.ac" is a regular Bourne shell script (i.e., "sh" -- not
|
|
csh!), except that capitalized names starting with "AC_" are Autoconf
|
|
macros. Normally you shouldn't have to touch them. You may refer to
|
|
the GNU Autoconf Manual for more info.
|
|
|
|
"make.sys.in" is the source file for "make.sys", that "configure"
|
|
generates: you might want to edit that file as well. The generation
|
|
procedure is as follows: if "configure.ac" contains the macro
|
|
"AC_SUBST(name)", then every occurrence of "@name@" in the source
|
|
files will be substituted with the value of the shell variable "name"
|
|
at the point where AC_SUBST was called.
|
|
|
|
"configure" writes a detailed log of its operation to "config.log".
|
|
When any configuration step fails, you may look there for the relevant
|
|
error messages. Note that it is normal for some checks to fail.
|
|
|
|
----------------------------------------------------------------------
|
|
HOW TO ADD SUPPORT FOR A NEW ARCHITECTURE
|
|
|
|
In order to support a previously unsupported architecture, first you
|
|
have to figure out which compilers, compilation flags, libraries
|
|
etc. should be used for compiling Quantum-ESPRESSO on that architecture.
|
|
In other words, you have to write a "make.sys" that works: use the
|
|
manual configuration procedure for that (see the Quantum-ESPRESSO User's
|
|
Guide). Then, you have to modify "configure" so that it can generate
|
|
that "make.sys" automatically.
|
|
|
|
To do that, you have to add the case for your architecture in several
|
|
places throughout "configure.ac":
|
|
|
|
*** 1: Detect architecture. ***
|
|
|
|
Look for these lines:
|
|
|
|
if test "$arch" = ""
|
|
then
|
|
# identify architecture
|
|
case $build in
|
|
ia64-*-linux-gnu | x86_64-*-linux-gnu ) arch=linux64 ;;
|
|
*-pc-linux-gnu ) arch=linux32 ;;
|
|
*-ibm-aix* ) arch=aix ;;
|
|
etc.
|
|
|
|
Here you must add an entry corresponding to your architecture and
|
|
operating system. Run "config.guess" to obtain the string identifying
|
|
your system.
|
|
For instance on a PC it may be "i686-pc-linux-gnu", while on IBM SP4
|
|
"powerpc-ibm-aix5.1.0.0". It is convenient to put some asterisks to
|
|
account for small variations of the string for different machines of
|
|
the same family. For instance, it could be "aix4.3" instead of
|
|
"aix5.1", or "athlon" instead of "i686"...
|
|
|
|
*** 2: Select compilers. ***
|
|
|
|
Look for these lines:
|
|
|
|
# check compiling environment
|
|
case $arch in
|
|
linux64 )
|
|
...
|
|
linux32 )
|
|
...
|
|
aix )
|
|
...
|
|
etc.
|
|
|
|
Add an entry for your value of $arch, and set there the appropriate
|
|
values for several variables:
|
|
|
|
- "try_f90" should contain the list of candidate Fortran 90 compilers,
|
|
in order of decreasing preference (i.e. configure will use the first
|
|
it finds). If your system has parallel compilers, you should list
|
|
them in "try_f90_parallel".
|
|
|
|
- "try_ar", "try_arflags": for these, the values "ar" and "ruv" should
|
|
be always fine, unless some special flag is required (e.g., -X64
|
|
with sp4). You should also set "ranlib=ranlib" if needed;
|
|
otherwise, the default of "ranlib=echo" will be used (i.e., don't
|
|
use ranlib).
|
|
|
|
- you should define "try_dflags" if the Quantum-ESPRESSO codes contain any
|
|
"#ifdef" specific to your machine: for instance "try_dflags=-D__AIX"
|
|
(on IBM machines) or "try_dflags=-D__LINUX" (on 32-bit PCs with
|
|
Linux) or "try_dflags=-D__LINUX64" (Linux on Itanium and Opteron).
|
|
|
|
For example, here's the entry for Mac OS X:
|
|
|
|
mac )
|
|
try_f90_parallel="mpxlf90 mpf90"
|
|
try_f90="xlf90 f90"
|
|
try_ar="ar"
|
|
try_arflags="ruv"
|
|
try_dflags="-D__MAC"
|
|
ranlib="ranlib"
|
|
;;
|
|
|
|
Then look for these lines:
|
|
|
|
# check Fortran 90 compiler
|
|
...
|
|
AC_PROG_F77($f90)
|
|
...
|
|
|
|
case "$arch:$f90" in
|
|
linux* )
|
|
...
|
|
aix:*xlf*_r )
|
|
...
|
|
etc.
|
|
|
|
and just below:
|
|
|
|
case "$arch:$f90" in
|
|
*:mpif90 )
|
|
....
|
|
etc.
|
|
|
|
In these two case blocks you have to add an entry for your
|
|
architecture *and* Fortran 90 compiler. There you have to set:
|
|
|
|
In the first case block:
|
|
|
|
- "try_cc", "try_f77": list of C and Fortran 77 compilers, also in
|
|
decreasing order of preference. This is done at this later stage
|
|
because the choice depends on the Fortran 90 compiler. For
|
|
instance, if $f90=ifort you'll want to use icc, while if $f90=pgf90
|
|
you'll want pgcc.
|
|
|
|
In the second case block:
|
|
|
|
- "try_cc_parallel", "try_f77_parallel": list of parallel C and
|
|
Fortran 77 compilers (if any).
|
|
|
|
A few compilers require some extra work here: for instance, if the
|
|
Intel Fortran compiler was selected, you need to know the version
|
|
because different versions need different flags.
|
|
|
|
For example, here are the entries for XL compilers on AIX:
|
|
|
|
aix:*xlf*_r )
|
|
try_cc="xlc_r cc gcc"
|
|
try_f77="xlf_r f77 $f90"
|
|
;;
|
|
|
|
aix:mpxlf*_r )
|
|
try_cc_parallel="mpcc_r"
|
|
try_f77_parallel="mpxlf_r"
|
|
;;
|
|
|
|
Finally, at this point:
|
|
|
|
# check whether the C and Fortran compilers are compatible
|
|
case "$arch:$cc:$f90" in
|
|
# list supported combinations here
|
|
...
|
|
|
|
you may insert the case corresponding to your architecture, with the
|
|
compilers that are known to work. Otherwise "configure" will write a
|
|
message like this:
|
|
|
|
----------------------------------------------
|
|
WARNING: the following problems were detected:
|
|
|
|
unsupported C/Fortran compilers combination:
|
|
CC=gcc, F77=f77, F90=g77
|
|
|
|
you may not be able to compile this program
|
|
----------------------------------------------
|
|
|
|
which you may however ignore.
|
|
|
|
*** 3: Specify compilation flags. ***
|
|
|
|
Look for these lines:
|
|
|
|
# check Fortran compiler flags
|
|
case "$arch:$f90_id" in
|
|
linux64:ifort | linux64:efc )
|
|
...
|
|
linux64:pgf* )
|
|
...
|
|
etc.
|
|
|
|
Add an entry for your case and define:
|
|
|
|
- "try_fflags": flags for Fortran 77 compiler.
|
|
|
|
- "try_f90flags": flags for Fortran 90 compiler.
|
|
In most cases they will be the same as in Fortran 77 plus some
|
|
others. In that case, define them as "\$(FFLAGS) -something_else".
|
|
|
|
- "try_fflags_noopt": flags for Fortran 77 with all optimizations
|
|
turned off: this is usually "-O0".
|
|
These flags must be used for compiling flib/dlamch.f (part of our
|
|
version of Lapack): it won't compile properly with optimizations.
|
|
|
|
- "try_ldflags": flags for the linking phase (not including the list
|
|
of libraries, that is compiled later). Note that $f90 will be used
|
|
as the linker, if not specified otherwise.
|
|
|
|
- "try_ldflags_static": additional flags to select static compilation
|
|
(i.e., don't use shared libraries).
|
|
|
|
- "try_dflags": must be defined if there is in the code any #ifdef
|
|
specific to your compiler (for instance, -D__INTEL for Intel
|
|
compilers). Define it as "$try_dflags -D..." so that pre-existing
|
|
flags, if any, are conserved.
|
|
|
|
- if the Fortran 90 compiler is able to invoke the C preprocessor
|
|
automatically before compiling, define "have_cpp=1"; otherwise,
|
|
leave it undefined (I mean it -- *don't* define it as 0).
|
|
The appropriate compilation rules will be generated accordingly.
|
|
If the compiler requires that any flags be specified in order to
|
|
invoke the preprocessor (for example, "-fpp " -- note the space),
|
|
specify them in "pre_fdflags".
|
|
|
|
For example, here's the entry for ifort on Linux PC:
|
|
|
|
linux32:ifort )
|
|
try_fflags="-Vaxlib -O2 -tpp6 -assume byterecl"
|
|
try_f90flags="\$(FFLAGS) -nomodule"
|
|
try_fflags_noopt="-O0"
|
|
try_ldflags="-Vaxlib"
|
|
try_ldflags_static="-static"
|
|
try_dflags="$try_dflags -D__INTEL"
|
|
pre_fdflags="-fpp "
|
|
have_cpp=1
|
|
;;
|
|
|
|
Then, look for these lines:
|
|
|
|
case "$arch:$cc_id" in
|
|
linux*:icc )
|
|
...
|
|
linux*:pgcc )
|
|
...
|
|
etc.
|
|
|
|
Add an entry for your case and define:
|
|
|
|
- "try_cflags": flags for C compiler.
|
|
|
|
- "c_ldflags": flags for linking, when using the C compiler as linker.
|
|
This is needed to check for libraries written in C, such as FFTW.
|
|
|
|
- if you need a different preprocessor from the standard one ($CC -E),
|
|
define it in "try_cpp".
|
|
|
|
For example for XLC on AIX:
|
|
|
|
aix:mpcc* | aix:xlc* | aix:cc )
|
|
try_cflags="-q64 -O2"
|
|
c_ldflags="-q64"
|
|
;;
|
|
|
|
Finally, if you have to use a nonstandard preprocessor, look for these
|
|
lines:
|
|
|
|
# preprocessor
|
|
AC_PROG_CPP
|
|
if test "$cpp" = "" ; then cpp=$try_cpp; fi
|
|
if test "$cpp" = "" ; then cpp=$CPP; fi
|
|
|
|
echo $ECHO_N "setting CPPFLAGS... $ECHO_C"
|
|
case $cpp in
|
|
cpp) try_cppflags="-P -traditional" ;;
|
|
fpp) try_cppflags="-P" ;;
|
|
...
|
|
|
|
and set "try_cppflags" as appropriate.
|
|
|
|
*** 4. Search for libraries. ***
|
|
|
|
To instruct "configure" to search for libraries, you must tell it two
|
|
things: the names of libraries it should search for, and where it
|
|
should search.
|
|
First, look for these lines:
|
|
|
|
# build list of directories to search
|
|
case "$arch" in
|
|
linux64 )
|
|
...
|
|
linux32 )
|
|
...
|
|
etc.
|
|
|
|
insert an entry for your architecture (and your compiler, if the
|
|
library to be searched for is compiler-specific), and define:
|
|
|
|
- "try_libdirs": a list of directories to search, separated by spaces.
|
|
|
|
Then, look for these lines:
|
|
|
|
# use vendor libraries if available
|
|
case "$arch" in
|
|
linux64 )
|
|
...
|
|
linux32 )
|
|
...
|
|
etc.
|
|
|
|
If you want to search for a vendor-specific library, you'll have to
|
|
add an entry for that library here.
|
|
|
|
This is unfortunately a little bit too complex to explain.
|
|
Basic info: "AC_SEARCH_LIBS(function, name, ...)" looks for symbol
|
|
"function" in library "libname". If that is found, "-lname" is
|
|
appended to the LIBS environment variable (initially empty).
|
|
The real thing is more complicated than just that because the
|
|
"-Ldirectory" option must be added to search in a nonstandard
|
|
directory, and because a given library may require other libraries as
|
|
prerequisites (for example, Lapack requires BLAS). Hope this helps.
|