build:fallbacks
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
build:fallbacks [2020/08/13 12:17] – [Project home] Jean-Michel Beuken | build:fallbacks [2020/08/19 12:55] (current) – [Building the fallbacks with Abinit] Jean-Michel Beuken | ||
---|---|---|---|
Line 47: | Line 47: | ||
Since the fallbacks evolve at a very different pace from Abinit and have very different objectives, they are available as a separate package. Typically, in one year, there will be 3 minor releases of Abinit, while 2 or 3 of the fallbacks at most will be upgraded asynchronously, | Since the fallbacks evolve at a very different pace from Abinit and have very different objectives, they are available as a separate package. Typically, in one year, there will be 3 minor releases of Abinit, while 2 or 3 of the fallbacks at most will be upgraded asynchronously, | ||
- | The independent fallbacks can be downloaded either from the Abinit Website. You can either download the source tarballs released with Abinit or clone one of the Git repositories directly. | + | The independent fallbacks can be downloaded either from the [[https:// |
==== Requirements ==== | ==== Requirements ==== | ||
Line 58: | Line 58: | ||
==== Getting the source code from the Abinit Website ==== | ==== Getting the source code from the Abinit Website ==== | ||
- | The official Abinit Fallbacks project page is [[https:// | + | The official Abinit Fallbacks project page is [[https:// |
If you are an active Abinit Developer, we highly recommend you to [[developers: | If you are an active Abinit Developer, we highly recommend you to [[developers: | ||
To get the latest version, just type the following: | To get the latest version, just type the following: | ||
- | <code bash>git clone abinit-forge: | + | <code bash>git clone abinit-forge: |
Line 70: | Line 70: | ||
When a new major or minor version of Abinit is about to be released, we usually package a snapshot of the fallbacks and distribute it as a source tarball. This file is called // | When a new major or minor version of Abinit is about to be released, we usually package a snapshot of the fallbacks and distribute it as a source tarball. This file is called // | ||
- | Source tarballs generated so far can be downloaded from Launchpad (https:// | + | /* Source tarballs generated so far can be downloaded from Launchpad (https:// |
+ | */ | ||
<WRAP info> | <WRAP info> | ||
Line 100: | Line 101: | ||
===== Building the fallbacks with Abinit ===== | ===== Building the fallbacks with Abinit ===== | ||
- | For convenience, | + | For convenience, |
+ | It is possible to build it along with Abinit, although much more efficient to build it and install it separately, since you do not have to rebuild the fallbacks each time you wish to make a new build of Abinit.\\ | ||
+ | /*Please note that the version of the fallbacks you may find within the Abinit source tree will perhaps | ||
- | Building the fallbacks within Abinit is mainly of interest to developers who want to experiment with compile flags and explore issues related to compilers and portability. It can also help - to a reduced extent only - users who are stuck within very rigid configurations and restricted build environments. Here is the way to proceed: | + | Building the fallbacks within Abinit is mainly of interest to developers who want to experiment with compile flags and explore issues related to compilers and portability. It can also help - to a reduced extent only - users who are stuck within very rigid configurations and restricted build environments.\\ |
+ | Here is the way to proceed: | ||
<code bash> | <code bash> | ||
tar xvzf abinit-x.y.z.tar.gz | tar xvzf abinit-x.y.z.tar.gz | ||
Line 108: | Line 112: | ||
mkdir tmp-build | mkdir tmp-build | ||
cd tmp-build | cd tmp-build | ||
- | ../ | + | |
- | | + | # Create a " |
- | # Abinit | + | ../ |
- | # fails because | + | </ |
- | cd transient | + | |
- | # Edit the build-abinit-fallbacks.sh script and set its install prefix | + | What happens in this case is that we first configure |
- | # as instructed therein | + | At this stage, |
+ | |||
+ | <code bash> | ||
+ | cd fallbacks | ||
./ | ./ | ||
- | make | + | |
- | make install | + | # At the end of the process, the script provides the options with prefixes to fallbacks. |
+ | # e.g. | ||
+ | # | ||
+ | # | ||
+ | # You can link these fallbacks with Abinit by copying the options to your ac9 file. | ||
cd .. | cd .. | ||
- | ../ | + | ../ |
- | | + | |
- | ... options ... | + | |
make -j8 # For example, if you have at least 8 cores available | make -j8 # For example, if you have at least 8 cores available | ||
make check | make check | ||
make install | make install | ||
</ | </ | ||
+ | /* ../ | ||
+ | * --with-fallbacks-prefix="/ | ||
+ | * ... options ... | ||
+ | */ | ||
- | What happens in this case is that we first configure Abinit, so that it generates all the necessary | + | Once the information |
+ | Next, Abinit uses them during its own build and we can install it normally after checking that everything is fine.\\ | ||
+ | In further builds with the same compiler, the same fallbacks | ||
- | Once the information is available to the configure script of the fallbacks, we can build them within | + | By default, |
+ | The variable // | ||
+ | Please note that this path must be absolute, i.e. start with a slash. \\ | ||
- | One line must be changed in the // | ||
<code bash> | <code bash> | ||
+ | #!/bin/bash | ||
+ | |||
+ | # Init | ||
+ | fallbacks_prefix=" | ||
+ | |||
+ | ... | ||
+ | </ | ||
+ | |||
+ | /* ------------------------------------------------------------------------------------------------- | ||
+ | One line must be changed in the // | ||
+ | |||
#!/bin/sh | #!/bin/sh | ||
Line 148: | Line 177: | ||
... | ... | ||
- | </code> | + | */ |
===== Using installed fallbacks ===== | ===== Using installed fallbacks ===== | ||
Line 182: | Line 211: | ||
. | . | ||
</ | </ | ||
- | where files are ordered by compiler vendor, then compiler version, and finally build variant. Each variant corresponds to a set of build parameters and is summarized by a keyword: | + | where files are ordered by compiler vendor |
* //gpu// for a GPU-aware configuration; | * //gpu// for a GPU-aware configuration; | ||
- | * //mpi// for a MPI-aware configuration; | + | * //openmpi// or //mpich// for a MPI-aware configuration; |
* //omp// for an OpenMP-aware configuration; | * //omp// for an OpenMP-aware configuration; | ||
* //sdebug// for a serial configuration with enhanced debug flags; | * //sdebug// for a serial configuration with enhanced debug flags; | ||
Line 203: | Line 232: | ||
==== The configuration of a package fails ==== | ==== The configuration of a package fails ==== | ||
- | Errors may appear at configure time when you build the fallbacks. In order to help you diagnose the problems, most packages provide a // | + | Errors may appear at configure time when you build the fallbacks. In order to help you diagnose the problems, most packages provide a // |
==== " | ==== " |
build/fallbacks.1597313829.txt.gz · Last modified: 2020/08/13 12:17 by Jean-Michel Beuken