Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
documentation:build:lammps [2018/02/15 16:31] frey [Intel compilers] |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Build from source: LAMMPS ====== | ||
| - | Start by setting-up a properly-versioned directory hierarchy for LAMMPS builds. For example: | ||
| - | |||
| - | <code bash> | ||
| - | $ mkdir -p ~/sw/lammps | ||
| - | $ cd ~/sw/lammps | ||
| - | $ mkdir attic | ||
| - | </code> | ||
| - | |||
| - | The ''attic'' directory is used to hold downloaded source packages, etc. I can download the latest LAMMPS stable source by visiting the [[http://lammps.sandia.gov/download.html|official downloads page]] and getting a "tarball" of the latest stable release. This usually downloads as ''lammps-stable.tar.gz'' which is slightly annoying because it doesn't cite the release date (so every release you download uses the same filename). When I upload the source to ''~/sw/lammps/attic'' I rename it: at the time of writing, the stable release is 11 August 2017, so I rename the file ''lammps-20170811.tar.gz'' to make that clear: | ||
| - | |||
| - | <code bash> | ||
| - | $ cd ~/sw/lammps | ||
| - | $ ls -l attic | ||
| - | total 117944 | ||
| - | -rw-r--r-- 1 frey cadmin 120774006 2018-02-14 13:42 lammps-20170811.tar.gz | ||
| - | </code> | ||
| - | |||
| - | Create a directory to hold the new version you are building. The name should include the release (version or date, etc.) and any special features worth mentioning. In this case, we'll be building the 11 August 2017 release without any special features: | ||
| - | |||
| - | <code bash> | ||
| - | $ cd ~/sw/lammps | ||
| - | $ mkdir 20170811 | ||
| - | $ ls -l | ||
| - | total 0 | ||
| - | drwxr-xr-x 2 frey cadmin 6 2018-02-14 13:45 20170811 | ||
| - | drwxr-xr-x 2 frey cadmin 35 2018-02-14 13:42 attic | ||
| - | </code> | ||
| - | |||
| - | Next, unpack the source code inside the version directory just created: | ||
| - | |||
| - | <code bash> | ||
| - | $ cd 20170811 | ||
| - | $ tar -zxf ../attic/lammps-20170811.tar.gz | ||
| - | $ ls -l | ||
| - | total 0 | ||
| - | drwxr-xr-x 10 frey cadmin 132 2017-08-11 14:19 lammps-11Aug17 | ||
| - | </code> | ||
| - | |||
| - | The directory structure we promote will have all the executables, libraries, etc. installed in the ''20170811'' directory; I typically rename the source code directory ''src'' rather than whatever name the program author(s) used: | ||
| - | |||
| - | <code bash> | ||
| - | $ mv lammps-11Aug17 src | ||
| - | $ cd src | ||
| - | $ ls -l | ||
| - | total 100 | ||
| - | drwxr-xr-x 5 frey cadmin 4096 2017-08-11 14:18 bench | ||
| - | drwxr-xr-x 5 frey cadmin 104 2017-08-11 14:23 doc | ||
| - | drwxr-xr-x 60 frey cadmin 4096 2017-08-11 14:18 examples | ||
| - | drwxr-xr-x 23 frey cadmin 4096 2017-08-11 14:18 lib | ||
| - | -rw-r--r-- 1 frey cadmin 17775 2017-07-24 10:58 LICENSE | ||
| - | drwxr-xr-x 2 frey cadmin 4096 2017-08-11 14:18 potentials | ||
| - | drwxr-xr-x 3 frey cadmin 84 2017-08-11 14:18 python | ||
| - | -rw-r--r-- 1 frey cadmin 1690 2011-09-23 19:48 README | ||
| - | drwxr-xr-x 66 frey cadmin 32768 2017-08-11 14:23 src | ||
| - | drwxr-xr-x 28 frey cadmin 4096 2017-08-11 14:19 tools | ||
| - | </code> | ||
| - | |||
| - | ===== Basic build configuration ===== | ||
| - | |||
| - | LAMMPS makes use of the Unix //make// command to manage the transformation of its source code into executables and libraries. There is no automated configuration or generation of a Makefile a'la GNU autoconf or CMake. Instead, a Makefile template is copied and edited by hand for each build variant: | ||
| - | |||
| - | <code bash> | ||
| - | $ cd src | ||
| - | $ ls -l MAKE | ||
| - | total 24 | ||
| - | drwxr-xr-x 2 frey cadmin 4096 2017-08-11 14:18 MACHINES | ||
| - | -rw-r--r-- 1 frey cadmin 2972 2016-05-12 09:54 Makefile.mpi | ||
| - | -rw-r--r-- 1 frey cadmin 2960 2016-05-12 09:54 Makefile.serial | ||
| - | drwxr-xr-x 2 frey cadmin 6 2017-08-11 14:18 MINE | ||
| - | drwxr-xr-x 2 frey cadmin 4096 2017-08-11 14:18 OPTIONS | ||
| - | -rw-r--r-- 1 frey cadmin 4797 2016-04-26 15:38 README | ||
| - | </code> | ||
| - | |||
| - | For a simple serial build using GNU compilers (''g++'') nothing needs to be done: the ''Makefile.serial'' can be used as-is. The suffix ''serial'' is a //machine// identifier in the LAMMPS build system. Assuming I have GNU compilers setup in my environment, the build is as simple as: | ||
| - | |||
| - | <code bash> | ||
| - | $ which g++ | ||
| - | /usr/bin/g++ | ||
| - | $ make serial | ||
| - | : | ||
| - | </code> | ||
| - | |||
| - | Quite a bit of information is displayed as the build proceeds: compilation commands for each individual source file, navigation through the source directory, and warning/error messages the compiler(s) may generate. A successful build will end with a summary line: | ||
| - | |||
| - | <code bash> | ||
| - | : | ||
| - | text data bss dec hex filename | ||
| - | 5722883 7744 968 5731595 57750b ../lmp_serial | ||
| - | make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial' | ||
| - | </code> | ||
| - | |||
| - | All of the intermediate object code files and the completed executable are found in the ''Obj_serial'' directory (if you're keeping track, that's ''~/sw/lammps/20170811/src/src/Obj_serial''). That directory name consists of the prefix ''Obj_'' and the LAMMPS //machine// name that was built. The executable itself is named ''lmp_«machine»'' and is in the ''src'' directory itself (where you issued the ''make'' command). | ||
| - | |||
| - | <WRAP center round tip 60%> | ||
| - | Since each build saves intermediate files and products in a separate directory, it is possible to build multiple variants of LAMMPS from the same source directory. If you create your own ''Makefile.«machine»'' just be sure to use a different //machine// name for each variant. | ||
| - | </WRAP> | ||
| - | |||
| - | The final task is to finish setting-up the ''20170811'' directory where we have the source code. At this point we've produced an executable, so it should be made available in a ''bin'' directory: | ||
| - | |||
| - | <code bash> | ||
| - | $ cd ~/sw/lammps/20170811 | ||
| - | $ mkdir -p bin | ||
| - | $ cd bin | ||
| - | $ cp ../src/src/lmp_serial lammps | ||
| - | $ ls -l | ||
| - | total 23956 | ||
| - | -rwxr-xr-x 1 frey cadmin 24529796 2018-02-14 14:24 lammps | ||
| - | $ ldd lammps | ||
| - | linux-vdso.so.1 => (0x00007fffa38d6000) | ||
| - | libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f8bf6eca000) | ||
| - | libm.so.6 => /lib64/libm.so.6 (0x00007f8bf6c74000) | ||
| - | libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8bf6a5d000) | ||
| - | libc.so.6 => /lib64/libc.so.6 (0x00007f8bf66ff000) | ||
| - | /lib64/ld-linux-x86-64.so.2 (0x00007f8bf71d5000) | ||
| - | </code> | ||
| - | |||
| - | In essence, you installed a copy of the finished executable in the ''bin'' directory; if you make changes to the build, they may affect the ''lmp_serial'' executable down in the ''src/src'' directory, but they won't affect your working executable until you do another such ''cp''. | ||
| - | |||
| - | <WRAP center round info 60%> | ||
| - | The ''ldd'' command shows what shared libraries an executable requires in order to run. If the right-hand side says that the library is not found, then you probably forgot to load a VALET package into your environment (e.g. setup ''LD_LIBRARY_PATH''). | ||
| - | </WRAP> | ||
| - | |||
| - | ===== Adding packages ===== | ||
| - | |||
| - | LAMMPS contains additional code that can be selectively included/excluded from the executable you build. These components are known as //packages// in the LAMMPS build system. Standard packages are provided by the LAMMPS authors; user packages are contributed code and use a name prefixed with ''USER-''. | ||
| - | |||
| - | Let's enable the LAMMPS built-in Python support (third variant on [[http://lammps.sandia.gov/doc/Section_python.html|this page]]) and rebuild our serial variant: | ||
| - | |||
| - | <code bash> | ||
| - | $ cd ~/sw/lammps/20170811/src/src | ||
| - | $ make package-status | grep -i python | ||
| - | Installed NO: package PYTHON | ||
| - | $ make yes-python | ||
| - | Installing package python | ||
| - | $ make serial | ||
| - | make[1]: Entering directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial' | ||
| - | make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial' | ||
| - | make[1]: Entering directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial' | ||
| - | g++ -g -O3 -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -DLMP_PYTHON -I../STUBS -c ../fix_python.cpp | ||
| - | ../fix_python.cpp:18:20: error: Python.h: No such file or directory | ||
| - | ../fix_python.cpp: In constructor ‘LAMMPS_NS::FixPython::FixPython(LAMMPS_NS::LAMMPS*, int, char**)’: | ||
| - | ../fix_python.cpp:55: error: ‘PyGILState_STATE’ was not declared in this scope | ||
| - | : | ||
| - | ../fix_python.cpp:111: error: ‘PyGILState_Release’ was not declared in this scope | ||
| - | make[1]: *** [fix_python.o] Error 1 | ||
| - | make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial' | ||
| - | make: *** [serial] Error 2 | ||
| - | </code> | ||
| - | |||
| - | This time the build was not successful. The first error cited indicates that there is no Python development package installed with our operating system: ''Python.h'' is the C header file that describes the Python API when programs wish to use the Python library. | ||
| - | |||
| - | <WRAP center round tip 60%> | ||
| - | If you are building LAMMPS on your own Linux computer, you can easily remedy this problem by installing the Python development package for your OS. E.g. for RedHat/CentOS systems, doing ''yum install python-devel'' as root should be sufficient. | ||
| - | </WRAP> | ||
| - | |||
| - | On our clusters, the VALET configuration management tool is used to selectively add software to the environment: | ||
| - | |||
| - | <code bash> | ||
| - | $ vpkg_versions python | ||
| - | Available versions in package (* = default version): | ||
| - | python Python Programming Language | ||
| - | 2.7.13 Version 2.7.13 | ||
| - | * 3.2.3 Version 3.2.3 | ||
| - | 3.2 (alias of 3.2.3) | ||
| - | 3 (alias of 3.2.3) | ||
| - | 2.7 (alias of 2.7.13) | ||
| - | $ vpkg_devrequire python/2.7 | ||
| - | Adding package `python/2.7.13` to your environment | ||
| - | </code> | ||
| - | |||
| - | Since LAMMPS requires us to manually maintain Makefiles, we will make our own //machine// similar to ''serial'': | ||
| - | |||
| - | <code bash> | ||
| - | $ cp MAKE/Makefile.serial MAKE/MINE/Makefile.local_serial | ||
| - | </code> | ||
| - | |||
| - | Edit the ''MAKE/MINE/Makefile.local_serial'' to modify: | ||
| - | * the line that sets the value of ''CCFLAGS'' | ||
| - | * the line that sets the value of ''LINKFLAGS'' | ||
| - | * the line that sets the value of ''LIB'' | ||
| - | |||
| - | <code> | ||
| - | : | ||
| - | CC = g++ | ||
| - | CCFLAGS = -g -O3 $(CPPFLAGS) | ||
| - | SHFLAGS = -fPIC | ||
| - | DEPFLAGS = -M | ||
| - | |||
| - | LINK = g++ | ||
| - | LINKFLAGS = -g -O $(LDFLAGS) | ||
| - | LIB = -lpython2.7 | ||
| - | : | ||
| - | </code> | ||
| - | |||
| - | Since the VALET ''vpkg_devrequire'' command adds appropriate header and library paths to the ''CPPFLAGS'' and ''LDFLAGS'' environment variables, we need only add their value to the other flags specified in the Makefile. The Python library must be added to the linking command via the ''LIB'' variable. A build is now successful: | ||
| - | |||
| - | <code bash> | ||
| - | $ make local_serial | ||
| - | : | ||
| - | text data bss dec hex filename | ||
| - | 6513443 8048 968 6522459 63865b ../lmp_local_serial | ||
| - | make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial' | ||
| - | </code> | ||
| - | |||
| - | This variant of LAMMPS has the capability of embedding Python code inside the job input file. When I'm ready to use this variant of the build, I can copy the executable to the ''bin'' directory: | ||
| - | |||
| - | <code bash> | ||
| - | $ cp lmp_local_serial ../../bin/lammps | ||
| - | </code> | ||
| - | |||
| - | <WRAP center round important 60%> | ||
| - | Linking against libraries installed in non-standard locations (e.g. not ''/lib64'' or ''/usr/lib'') means that this executable depends on the ''python/2.7'' VALET package's being added to the environment. It is beneficial to create your own VALET package for your LAMMPS builds and include such dependencies within each version's specification. If you build LAMMPS using only libraries provided by your operating system, such dependencies will not exist -- but it would still be advisable to create a VALET package to manage your versions of the program! | ||
| - | </WRAP> | ||
| - | |||
| - | ===== Alternate compilers ===== | ||
| - | |||
| - | After logging out for a time, I've returned and want to try adding the //KOKKOS// package to the build: | ||
| - | |||
| - | <code bash> | ||
| - | $ cd ~/sw/lammps/20170811/src/src | ||
| - | $ vpkg_devrequire python/2.7 | ||
| - | Adding package `python/2.7.13` to your environment | ||
| - | $ make yes-KOKKOS | ||
| - | Installing package KOKKOS | ||
| - | $ make local_serial | ||
| - | : | ||
| - | g++ -g -O3 -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -DLMP_KOKKOS -DLMP_PYTHON -I../STUBS -I./ -I../../lib/kokkos/core/src -I../../lib/kokkos/containers/src -I../../lib/kokkos/algorithms/src --std=c++11 -fopenmp -c ../angle_charmm.cpp | ||
| - | cc1plus: error: unrecognized command line option "-std=c++11" | ||
| - | make[1]: *** [angle_charmm.o] Error 1 | ||
| - | make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial' | ||
| - | make: *** [local_serial] Error 2 | ||
| - | </code> | ||
| - | |||
| - | The GNU C++ compiler does not understand a command-line option that the KOKKOS code has added: ''--std=c++11'' indicates a particular dialect of C++ that the compiler should target, and isn't available in the GCC 4.3.4 compiler collection we are using. The GCC 4.9 compilers do accept that flag, and we just happen to have that compiler available: | ||
| - | |||
| - | <code bash> | ||
| - | $ vpkg_versions gcc | ||
| - | Available versions in package (* = default version): | ||
| - | gcc GNU Compiler Suite | ||
| - | * system OS-default GCC installation | ||
| - | 4.9.3 Version 4.9.3 | ||
| - | 4.9 (alias of 4.9.3) | ||
| - | $ vpkg_require gcc/4.9 | ||
| - | Adding package `gcc/4.9.3` to your environment | ||
| - | $ which g++ | ||
| - | /data/opt/gcc/4.9.3/bin/g++ | ||
| - | </code> | ||
| - | |||
| - | Since the appropriate directories were added to the ''PATH'' environment variable, the command ''g++'' no longer maps to ''/usr/bin/g++'' but to the 4.9.3 version; thus, we do not need to alter our ''Makefile.local_serial'' to change the value of ''CC'' and ''LINK''! Before proceeding, we need to clean-out all the previous object code files: since they were produced with a different version of the compiler, it's best to start anew: | ||
| - | |||
| - | <code bash> | ||
| - | $ make clean-local_serial | ||
| - | : | ||
| - | $ make local_serial | ||
| - | : | ||
| - | text data bss dec hex filename | ||
| - | 12719862 11624 315272 13046758 c713e6 ../lmp_local_serial | ||
| - | make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial' | ||
| - | $ ldd lmp_local_serial | ||
| - | linux-vdso.so.1 => (0x00007fff591ff000) | ||
| - | libdl.so.2 => /lib64/libdl.so.2 (0x00007f5ee96c8000) | ||
| - | libpython2.7.so.1.0 => /opt/python/2.7.13/lib/libpython2.7.so.1.0 (0x00007f5ee92ce000) | ||
| - | libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5ee90b1000) | ||
| - | libutil.so.1 => /lib64/libutil.so.1 (0x00007f5ee8eae000) | ||
| - | libstdc++.so.6 => /data/opt/gcc/4.9.3/lib64/libstdc++.so.6 (0x00007f5ee8b96000) | ||
| - | libm.so.6 => /lib64/libm.so.6 (0x00007f5ee8940000) | ||
| - | libgomp.so.1 => /data/opt/gcc/4.9.3/lib64/libgomp.so.1 (0x00007f5ee8729000) | ||
| - | libgcc_s.so.1 => /data/opt/gcc/4.9.3/lib64/libgcc_s.so.1 (0x00007f5ee8512000) | ||
| - | libc.so.6 => /lib64/libc.so.6 (0x00007f5ee81b4000) | ||
| - | /lib64/ld-linux-x86-64.so.2 (0x00007f5ee98cc000) | ||
| - | librt.so.1 => /lib64/librt.so.1 (0x00007f5ee7fab000) | ||
| - | $ cp lmp_local_serial ../../bin/lammps | ||
| - | </code> | ||
| - | |||
| - | Note that there are now additional shared libraries referenced by the executable. Before running this copy both the Python and GCC packages used to build it must be added to the environment: | ||
| - | |||
| - | <code bash> | ||
| - | $ vpkg_require python/2.7 gcc/4.9 | ||
| - | Adding package `python/2.7.13` to your environment | ||
| - | Adding package `gcc/4.9.3` to your environment | ||
| - | $ ldd ~/sw/lammps/20170811/bin/lammps | ||
| - | linux-vdso.so.1 => (0x00007fff49fb6000) | ||
| - | libdl.so.2 => /lib64/libdl.so.2 (0x00007f5fa712c000) | ||
| - | libpython2.7.so.1.0 => /opt/python/2.7.13/lib/libpython2.7.so.1.0 (0x00007f5fa6d32000) | ||
| - | libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5fa6b15000) | ||
| - | libutil.so.1 => /lib64/libutil.so.1 (0x00007f5fa6912000) | ||
| - | libstdc++.so.6 => /data/opt/gcc/4.9.3/lib64/libstdc++.so.6 (0x00007f5fa65fa000) | ||
| - | libm.so.6 => /lib64/libm.so.6 (0x00007f5fa63a4000) | ||
| - | libgomp.so.1 => /data/opt/gcc/4.9.3/lib64/libgomp.so.1 (0x00007f5fa618d000) | ||
| - | libgcc_s.so.1 => /data/opt/gcc/4.9.3/lib64/libgcc_s.so.1 (0x00007f5fa5f76000) | ||
| - | libc.so.6 => /lib64/libc.so.6 (0x00007f5fa5c18000) | ||
| - | /lib64/ld-linux-x86-64.so.2 (0x00007f5fa7330000) | ||
| - | librt.so.1 => /lib64/librt.so.1 (0x00007f5fa5a0f000) | ||
| - | </code> | ||
| - | |||
| - | <WRAP center round info 60%> | ||
| - | KOKKOS was automatically configured by the LAMMPS build environment to use the OpenMP "device." Thus, the pthread and gomp (**G**NU **O**pen**MP**) libraries are used by the executable. To influence which KOKKOS device(s) are enabled, set the ''KOKKOS_DEVICES'' variable in your Makefile. See the ''src/MAKE/OPTIONS/Makefile.kokkos_*'' files for examples. | ||
| - | </WRAP> | ||
| - | |||
| - | ==== Intel compilers ==== | ||
| - | |||
| - | Were we to switch to using the Intel C++ compiler (''icpc'') to build the program, not only would the value of the ''CC'' and ''LINK'' variable change in the Makefile, many of the command-line options would be different, as well. The authors of LAMMPS provide additional Makefile templates that include optimal flags for alternate compilers under the ''src/MAKE/OPTIONS'' directory. In particular, ''src/MAKE/OPTIONS/Makefile.icc_serial'' would be a helpful starting point. As before, the best practice would be to make a copy of that template in the ''src/MAKE/MINE'' directory and edit it. | ||
| - | |||
| - | ===== Packages with provided libraries ===== | ||
| - | |||
| - | One popular add-on package to LAMMPS is the //reax// package, not to be confused with the //user-reaxc// package. The latter is written in C and is very simple to enable: | ||
| - | |||
| - | <code bash> | ||
| - | $ make yes-user-reaxc | ||
| - | Installing package user-reaxc | ||
| - | updating package KOKKOS | ||
| - | updating src/fix_qeq_reax_kokkos.cpp | ||
| - | updating src/fix_qeq_reax_kokkos.h | ||
| - | updating src/fix_reaxc_bonds_kokkos.cpp | ||
| - | updating src/fix_reaxc_bonds_kokkos.h | ||
| - | updating src/fix_reaxc_species_kokkos.cpp | ||
| - | updating src/fix_reaxc_species_kokkos.h | ||
| - | updating src/pair_reaxc_kokkos.cpp | ||
| - | updating src/pair_reaxc_kokkos.h | ||
| - | $ make local_serial | ||
| - | : | ||
| - | text data bss dec hex filename | ||
| - | 13554595 11904 315528 13882027 d3d2ab ../lmp_local_serial | ||
| - | make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial' | ||
| - | </code> | ||
| - | |||
| - | The //reax// package interfaces with an external Fortran library that is included in the LAMMPS source distribution: | ||
| - | |||
| - | <code bash> | ||
| - | $ make yes-reax | ||
| - | Installing package reax | ||
| - | $ make local_serial | ||
| - | make[1]: Entering directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial' | ||
| - | Makefile.package.settings:4: ../../lib/reax/Makefile.lammps: No such file or directory | ||
| - | make[1]: *** No rule to make target `../../lib/reax/Makefile.lammps'. Stop. | ||
| - | make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial' | ||
| - | make[1]: Entering directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial' | ||
| - | Makefile.package.settings:4: ../../lib/reax/Makefile.lammps: No such file or directory | ||
| - | make[1]: *** No rule to make target `../../lib/reax/Makefile.lammps'. Stop. | ||
| - | make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial' | ||
| - | make: *** [local_serial] Error 2 | ||
| - | </code> | ||
| - | |||
| - | Before building LAMMPS with the //reax// package enabled, that Fortran library must be built. The library resides in the ''lib'' directory above the ''src'' directory in which we are currently working: | ||
| - | |||
| - | <code bash> | ||
| - | $ cd ../lib/reax | ||
| - | $ less README | ||
| - | </code> | ||
| - | |||
| - | The ''README'' file describes how to build the package. | ||