diff --git a/docs/Changelog.rst b/docs/Changelog.rst index aff4af40..d2243e4a 100644 --- a/docs/Changelog.rst +++ b/docs/Changelog.rst @@ -3,6 +3,29 @@ Changelog for EasyBuild documentation ------------------------------------- +* **release 20150430.01** (`Apr 30th 2015`): updated documentation for EasyBuild v2.1.0 + + * also cover extensions in page on concepts and terminology (see :ref:`extensions`) + * add documentation on :ref:`partial_installations`, covering ``--stop``, ``--skip`` and ``--module-only`` + * add documentation on :ref:`manipulating_dependencies`, covering ``--filter-deps`` and ``--hide-deps`` + * document ``-module-syntax`` configuration option (see :ref:`module_syntax`) + * add note on detection of unknown ``$EASYBUILD``-prefixed environment variables (see :ref:`configuration_env_vars`) + * mention support for prepending/appending to ``--robot-paths`` (see :ref:`robot_search_path_prepend_append`) + * update release notes for EasyBuild v2.1.0 (see :ref:`release_notes`) + +* **release 20150425.01** (`Apr 25th 2015`): + + * add documentation on :ref:`using_external_modules` + +* **release 20150407.01** (`Apr 7th 2015`): + + * add link to :ref:`unit_tests` page in dedicated section at :ref:`installation` page + (see :ref:`install_running_unit_tests`) + * clarify relation between ``--installpath``, ``--prefix``, ``-subdir-*`` and ``--installpath-*`` + configuration options (see :ref:`installpath`) + * mention ``--show-default-configfiles`` command line option in relevant section + (see :ref:`default_configuration_files`) + * **release 20150327.01** (`Mar 27th 2015`): * documented deprecated functionality w.r.t. error reporting (see :ref:`depr_error_reporting`) diff --git a/docs/Concepts_and_Terminology.rst b/docs/Concepts_and_Terminology.rst index cfdb59d9..c80e9687 100644 --- a/docs/Concepts_and_Terminology.rst +++ b/docs/Concepts_and_Terminology.rst @@ -153,3 +153,20 @@ Therefore, reproducing installations becomes trivial. EasyBuild version |version| includes support for over 511 different software packages, spread over 2800 easyconfig files describing distinct builds. + +.. _extensions: + +Extensions +---------- + +Some software packages support installing additional add-ons alongside the 'main' software, either in the same +installation prefix, or in a separate location. + +In EasyBuild, we use the neutral term '**extensions**' to refer these add-ons. + +Well-known examples include: + +* Perl modules (http://www.cpan.org/modules/) +* Python packages (https://pypi.python.org/pypi) +* R libraries (http://cran.r-project.org/web/packages/) +* Ruby gems (http://guides.rubygems.org/what-is-a-gem/) diff --git a/docs/Configuration.rst b/docs/Configuration.rst index 19f92108..214ed45a 100644 --- a/docs/Configuration.rst +++ b/docs/Configuration.rst @@ -27,7 +27,8 @@ is even fairly common). The order of preference for the different configuration types is as listed above, that is: * environment variables override the corresponding entries in the configuration file -* command line arguments in turn override the corresponding environment variables *and* matching entries in the configuration file +* command line arguments in turn override the corresponding environment variables *and* matching entries in the + configuration file Consistentency across supported configuration types @@ -98,6 +99,21 @@ configuration files at ``/etc/easybuild.d/*.cfg`` and ``$HOME/.config/easybuild/ The configuration file located in ``$XDG_CONFIG_HOME`` will be listed *after* the ones obtained via ``$XDG_CONFIG_DIRS``, such that user-defined configuration settings have preference over system defaults. +A detailed overview of the list of default configuration files is available via ``eb --show-default-configfiles`` +(available since EasyBuild v2.1.0). For example:: + + $ XDG_CONFIG_DIRS=/tmp/etc:/tmp/moreetc eb --show-default-configfiles + Default list of configuration files: + + [with $XDG_CONFIG_HOME: (not set), $XDG_CONFIG_DIRS: /tmp/etc:/tmp/moreetc] + + * user-level: ${XDG_CONFIG_HOME:-$HOME/.config}/easybuild/config.cfg + -> /home/example/.config/easybuild/config.cfg => found + * system-level: ${XDG_CONFIG_DIRS:-/etc}/easybuild.d/*.cfg + -> {/tmp/etc, /tmp/moreetc}/easybuild.d/*.cfg => /tmp/etc/easybuild.d/config.cfg, /tmp/moreetc/easybuild.d/bar.cfg, /tmp/moreetc/easybuild.d/foo.cfg + + Default list of existing configuration files (4): /tmp/etc/easybuild.d/config.cfg, /tmp/moreetc/easybuild.d/bar.cfg, /tmp/moreetc/easybuild.d/foo.cfg, /home/example/.config/easybuild/config.cfg + Multiple configuration files ++++++++++++++++++++++++++++ @@ -159,11 +175,8 @@ Templates and constants supported in configuration files Two types of template values ``%(...)s`` are supported in configuration files: * for configuration options defined in the configuration file (and only those) - * *syntax:* ``%(opt)s``, i.e., using the (lowercase) name of the configuration option - * for the default value of selected configuration options (see ``eb --avail-cfgfile-constants``) - * *syntax:* ``%(DEFAULT_OPT)s``, i.e., using the uppercase name of the configuration option and prefixed with ``DEFAULT_`` .. note:: @@ -213,6 +226,8 @@ file. This can be used as an empty template configuration file: [basic] # Print build overview incl. dependencies (full paths) (def False) +.. _configuration_env_vars: + Environment variables ~~~~~~~~~~~~~~~~~~~~~ @@ -234,6 +249,8 @@ shown in the sections below. .. tip:: Any configuration option of EasyBuild which can be tuned by command line or via the configuration file, can also be tuned via a corresponding environment variable. +.. note:: If any ``$EASYBUILD``-prefixed environment variables are defined that do not correspond to a known + configuration option, EasyBuild will report an error message and exit. Command line arguments ~~~~~~~~~~~~~~~~~~~~~~ @@ -291,13 +308,15 @@ If any of these configuration settings is not provided in one way or another, Ea In practice, all of these have reasonable defaults (see ``eb --help`` for the default settings). +.. note:: The mandatory path-related options can be tweaked collectively via ``--prefix``, see :ref:`prefix` for more + information. .. _sourcepath: Source path (``--sourcepath``) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -*default*: ``$HOME/.local/easybuild/sources/`` +*default*: ``$HOME/.local/easybuild/sources/`` (determined via :ref:`prefix`) The ``sourcepath`` configuration setting specifies the parent path of the directory in which EasyBuild looks for software source and install files. @@ -306,7 +325,8 @@ Looking for the files specified via the ``sources`` parameter in the .eb easyconfig file is done in the following order of preference: * ``/``: a subdirectory determined by the name of the software package -* ``//``: in the style of the ``easyblocks``/``easyconfigs`` directories: in a subdirectory determined by the first letter (in lower case) of the software package and by its full ``name`` +* ``//``: in the style of the ``easyblocks``/``easyconfigs`` directories: in a + subdirectory determined by the first letter (in lower case) of the software package and by its full ``name`` * ````: directly in the source path Note that these locations are also used when EasyBuild looks for patch @@ -317,7 +337,7 @@ files in addition to the various ``easybuild/easyconfigs`` directories that are Build path (``--buildpath``) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -*default*: ``$HOME/.local/easybuild/build/`` +*default*: ``$HOME/.local/easybuild/build/`` (determined via :ref:`prefix`) The ``buildpath`` configuration setting specifies the parent path of the (temporary) directories in which EasyBuild builds its software packages. @@ -337,48 +357,92 @@ when the installation is completed (by default). .. _installpath: -Install path (``--installpath``) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Software and modules install path (``--installpath``, ``--installpath-software``, ``--installpath-modules``) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +defaults: + +* *software install path:* ``$HOME/.local/easybuild/software`` (determined via :ref:`prefix` and ``--subdir-software``) +* *modules install path:* ``$HOME/.local/easybuild/modules/all`` (determined via :ref:`prefix`, + ``--subdir-modules`` and ``--suffix-modules-path``) + +There are several ways in which the software and modules install path used by EasyBuild can be configured: -*default*: ``$HOME/.local/easybuild/`` +* using the direct configuration options ``--installpath-software`` and ``--installpath-modules`` (see below) +* via the parent install path configuration option ``--installpath`` (see below) +* via the overall prefix path configuration option ``--prefix`` (see :ref:`prefix`) -The ``installpath`` configuration setting specifies the parent path of -the directories in which EasyBuild installs software packages and the +.. _installpath_direct_options: + +Direct options: ``--installpath-software`` and ``--installpath-modules`` +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +*default*: *(no default specified)* + +The ``--installpath-software`` and ``--installpath-modules`` configuration options (available since EasyBuild v2.1.0) +allow to directly specify the software and modules install paths, respectively. + +These configuration options have precedence over all of the other configuration options that relate to specifying the +install path for software and/or modules (see below). + +.. _parent_installpath: + +Parent install path: ``--installpath`` +++++++++++++++++++++++++++++++++++++++ + +*default*: *(no default specified)* + +The ``--installpath`` configuration option specifies the *parent* path of +the directories in which EasyBuild should install software packages and the corresponding module files. -By default, the packages themselves are installed under ``/software`` -in their own subdirectory following the active module naming scheme -(e.g., ``/-``, by default). -The corresponding module files are installed under -``/modules/all``, and symlinks are installed in ``/modules/``. +The install path for software and modules specifically is determined by combining ``--installpath`` with +``--subdir-software``, and combining ``--installpath`` with ``--subdir-modules`` and ``--suffix-modules-path``, +respectively. + +For more information on these companion configuration options, see :ref:`installpath_subdirs`. + +Full install path for software and module file +++++++++++++++++++++++++++++++++++++++++++++++ + +The full software and module install paths for a particular software package are determined by the active +module naming scheme along with the general software and modules install paths specified by the EasyBuild configuration. + +Both the software itself and the corresponding module file will be installed in a subdirectory of the corresponding +install path named according to the active module naming scheme (default format: +``/-``). +Additionally, symlinks to the actual module file are installed in a subdirectory of the modules install path +named according to the value of the ``moduleclass`` easyconfig parameter. -Different configuration options are available for changing the default behaviour, i.e., ---subdir-software, --subdir-modules, --suffix-modules-path, --module-naming-scheme, etc. +For more information on the module naming scheme used by EasyBuild, see :ref:`module_naming_scheme`. -For more information, see `Optional configuration settings`_. +Updating ``$MODULEPATH`` +++++++++++++++++++++++++ -Setting ``$MODULEPATH`` -+++++++++++++++++++++++ +To make the modules generated by EasyBuild available, the ``$MODULEPATH`` environment variable must be updated +to include the modules install path. -After (re)configuring EasyBuild, you need to make sure that -``$MODULEPATH`` environment variable is extended with the -``modules/all`` subdirectory of the ``installpath`` -so you can load the modules created for the software built with EasyBuild, i.e.: +The recommended way to do this is to use the ``module use`` command. +For example: .. code:: shell-session - $ module use /modules/all + $ eb --installpath=$HOME/easybuild + $ module use $HOME/easybuild/modules/all It is probably a good idea to add this to your (favourite) shell ``.rc`` file, e.g., ``~/.bashrc``, and/or the ``~/.profile`` login scripts, so you do not need to adjust ``$MODULEPATH`` every time you start a new session. +.. note:: Updating ``$MODULEPATH`` is not required for EasyBuild itself, since ``eb`` updates ``$MODULEPATH`` itself at + runtime according to the modules install path it is configured with. + .. _easyconfigs_repo: Easyconfigs repository (``--repository``, ``--repositorypath``) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -*default*: ``FileRepository`` at ``$HOME/.local/easybuild/ebfiles_repo`` +*default*: ``FileRepository`` at ``$HOME/.local/easybuild/ebfiles_repo`` (determined via :ref:`prefix`) EasyBuild has support for archiving (tested) ``.eb`` easyconfig files. After successfully installing a software package using EasyBuild, the @@ -386,20 +450,17 @@ corresponding ``.eb`` file is uploaded to a repository defined by the ``reposito Currently, EasyBuild supports the following repository types (see also ``eb --avail-repositories``): - * ``FileRepository('path', 'subdir')``: a plain flat file repository; - ``path`` is the path where files will be stored, ``subdir`` is an - *optional* subdirectory of - that path where the files should be stored + ``path`` is the path where files will be stored, ``subdir`` is an + *optional* subdirectory of that path where the files should be stored * ``GitRepository('path', 'subdir/in/repo'``: a *non-empty* **bare** - git repository (created with ``git init --bare`` or ``git clone --bare``); - ``path`` is the path to the git repository (can also be a URL); - ``subdir/in/repo`` is optional, and specifies a subdirectory of the - repository where files should be stored in + git repository (created with ``git init --bare`` or ``git clone --bare``); + ``path`` is the path to the git repository (can also be a URL); + ``subdir/in/repo`` is optional, and specifies a subdirectory of the + repository where files should be stored in * ``SvnRepository('path', 'subdir/in/repo')``: an SVN repository; - ``path`` contains the subversion repository location (directory or - URL), the optional second value - specifies a subdirectory in the repository + ``path`` contains the subversion repository location (directory or + URL), the optional second value specifies a subdirectory in the repository You need to set the ``repository`` setting inside a configuration file like this: @@ -469,24 +530,44 @@ template value here):: Optional configuration settings ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Software and modules install path suffixes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +.. _prefix: + +Overall prefix path (``--prefix``) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +*default:* ``$HOME/.local/easybuild`` + +The overall prefix path used by EasyBuild can be specified using the ``--prefix`` configuration option. + +This affects the default value of several configuration options: + +* source path (see :ref:`sourcepath`) +* build path (see :ref:`buildpath`) +* software and modules install path (see :ref:`installpath`) +* easyconfigs repository path (see :ref:`easyconfigs_repo`) -This section describes configuration options -``--subdir-software``, ``--subdir-modules``, ``--suffix-modules-path``, -which are supported since v1.14.0. +.. _installpath_subdirs: -*defaults*: ``software`` as software install path suffix, ``modules`` as -modules install path suffix +Software and modules install path subdirectories (``--subdir-software``, ``--subdir-modules``, ``--suffix-modules-path``) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The software and modules install path suffixes can be adjusted using the -``subdir-software`` and/or ``subdir-modules`` / ``suffix-modules-path`` configuration settings, -for example: +*defaults*: + +* *software install path subdirectory* (``--subdir-software``): ``software`` +* *modules install path subdirectory* (``--subdir-modules``): ``modules`` +* *modules install path suffix* (``--suffix-modules-path``): ``all`` + +The subdirectories for the software and modules install paths (relative to ``--installpath``, see :ref:`installpath`) +can be specified using the corresponding dedicated configuration options (available since EasyBuild v1.14.0). + +For example: .. code:: shell-session $ export EASYBUILD_SUBDIR_SOFTWARE=installs - $ eb --subdir-modules=module_files ... + $ eb --installpath=$HOME/easybuild --subdir-modules=module_files ... + +.. _modules_tool: Modules tool (``--modules-tool``) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -515,6 +596,8 @@ For example, to indicate that EasyBuild should be using ``Lmod`` as modules tool $ eb --modules-tool=Lmod ... +.. _module_naming_scheme: + Active module naming scheme (``--module-naming-scheme``) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -531,3 +614,40 @@ For more details, see the dedicated page: https://github.com/hpcugent/easybuild/ .. _`http://docs.python.org/2/library/configparser.html`: http://docs.python.org/2/library/configparser.html +.. _module_syntax: + +Module files syntax (``--module-syntax``) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +*default*: ``Tcl`` + +*supported since*: EasyBuild v2.1 + +The syntax to use for generated module files can be specified using the ``--module-syntax`` configuration setting. + +Possible values are: + +* ``Lua``: generate module files in Lua syntax + + * this requires the use of Lmod as a modules tool to consume the module files (see :ref:`modules_tool`) + * module file names will have the ``.lua`` extension + +* ``Tcl``: generate module files in Tcl syntax + + * Tcl module files can be consumed by all supported modules tools + * module files will contain a header string ``#%Module`` indicating that they are composed in Tcl syntax + +.. note:: + Lmod is able to deal with having module files in place in both Tcl and Lua syntax. When a module file in Lua + syntax (i.e., with a ``.lua`` file name extension) is available, a Tcl module file with the same name will be + ignored. The Tcl-based environment modules tool will simply ignore module files in Lua syntax, since they do not + contain the header string that is included in Tcl module files. + +.. note:: + Using module files in Lua syntax has the advantage that Lmod does not need to translate from Lua to Tcl internally + when processing the module files, which benefits responsiveness of Lmod when used interactively by users. In terms + of Lmod-specific aspects of module files, the syntax of the module file does *not* matter; Lmod-specific statements + supported by EasyBuild can be included in Tcl module files as well, by guarding them by a condition that only + evaluates positively when Lmod is consuming the module file, i.e. + '``if { [ string match "*tcl2lua.tcl" $env(_) ] } { ... }``'. Only conditional load statements like + '``load(atleast("gcc","4.8"))``' can only be used in Lua module files. diff --git a/docs/Installation.rst b/docs/Installation.rst index 8fc32c1b..825566bc 100644 --- a/docs/Installation.rst +++ b/docs/Installation.rst @@ -127,6 +127,8 @@ For example:: may make a big difference, if you have installed both versions 1.9.0 and 1.15.2, with respect to what is the version being loaded by default. +.. _install_running_unit_tests: + Running unit tests ~~~~~~~~~~~~~~~~~~ @@ -135,6 +137,8 @@ After completion of the bootstrap procedure and loading the python -m test.framework.suite +More details about the EasyBuild unit tests are available at :ref:`unit_tests`. + If this does not complete successfully, `please open an issue`_ to report it. .. _please open an issue: https://github.com/hpcugent/easybuild-framework/issues/new diff --git a/docs/Manipulating_dependencies.rst b/docs/Manipulating_dependencies.rst new file mode 100644 index 00000000..76feb2ac --- /dev/null +++ b/docs/Manipulating_dependencies.rst @@ -0,0 +1,75 @@ +.. _manipulating_dependencies: + +Manipulating dependencies +========================= + +A couple of different ways are available to manipulate the list of dependencies that are specified for the software +packages being installed. + +.. _filter_deps: + +Filtering out dependencies using ``--filter-deps`` +-------------------------------------------------- + +To avoid that certain dependencies are being installed, a list of software names can be specified to ``--filter-deps``. +Any time a dependency with a name from this list is specified, it will be simply filtered out by EasyBuild, and +thus disregarded when resolving dependencies, loading modules for the dependencies in the build environment, and +including '``module load``' statements in the generated module files. + +This can be useful when particular tools and libraries are already provided by OS packages (or in some other way), +and should not be reinstalled as modules by EasyBuild. + +For example: + +* overview of dependencies of HDF5:: + + $ eb HDF5-1.8.13-intel-2015a.eb -D + ... + * [ ] $CFGS/i/intel/intel-2015a.eb (module: intel/2015a) + * [ ] $CFGS/z/zlib/zlib-1.2.8-intel-2015a.eb (module: zlib/1.2.8-intel-2015a) + * [ ] $CFGS/s/Szip/Szip-2.1-intel-2015a.eb (module: Szip/2.1-intel-2015a) + * [ ] $CFGS/h/HDF5/HDF5-1.8.13-intel-2015a.eb (module: HDF5/1.8.13-intel-2015a) + +* overview of dependencies of HDF5, with zlib and Szip excluded:: + + $ eb HDF5-1.8.13-intel-2015a.eb --filter-deps=zlib,Szip -D + ... + * [ ] $CFGS/i/intel/intel-2015a.eb (module: intel/2015a) + * [ ] $CFGS/h/HDF5/HDF5-1.8.13-intel-2015a.eb (module: HDF5/1.8.13-intel-2015a) + + +.. _hide_deps: + +Installing dependencies as hidden modules using ``--hide-deps`` +--------------------------------------------------------------- + +Selected software packages can be marked to be installed as hidden modules (i.e., modules that are not visible via +'``module avail``', but can be loaded) whenever they are included as a dependency, via the ``--hide-deps`` +configuration option. + +For example (note the preceding '``.``' in the last part of the module names for zlib and Szip):: + + $ eb HDF5-1.8.13-intel-2015a.eb --hide-deps=zlib,Szip -D + ... + * [ ] $CFGS/i/intel/intel-2015a.eb (module: intel/2015a) + * [ ] $CFGS/z/zlib/zlib-1.2.8-intel-2015a.eb (module: zlib/.1.2.8-intel-2015a) + * [ ] $CFGS/s/Szip/Szip-2.1-intel-2015a.eb (module: Szip/.2.1-intel-2015a) + * [ ] $CFGS/h/HDF5/HDF5-1.8.13-intel-2015a.eb (module: HDF5/1.8.13-intel-2015a) + +.. note:: + Using Lmod (version >= 5.7.5), hidden modules can be made visible in the output of '``module avail``' using the + ``--show-hidden`` option. + + For example:: + + $ module avail bzip2 + + Use "module spider" to find all possible modules. + Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys". + + $ module --show-hidden avail bzip2 + ----- /home/example/.local/easybuild/modules/all ----- + bzip2/.1.0.6 + + Use "module spider" to find all possible modules. + Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys". diff --git a/docs/Partial_installations.rst b/docs/Partial_installations.rst new file mode 100644 index 00000000..89c5b805 --- /dev/null +++ b/docs/Partial_installations.rst @@ -0,0 +1,269 @@ +.. _partial_installations: + +Partial installations +===================== + +Several ways of performing partial installations are supported. These may be useful when debugging a particular issue +with the installation procedure being performed by EasyBuild, updating existing software installations or module files, +or after changing the EasyBuild configuration (e.g., switching to module files in Lua syntax or a different module +naming scheme). + +* :ref:`partial_installation_stop` +* :ref:`partial_installation_skip` +* :ref:`module_only` + + * :ref:`module_only_only_regenerate` + * :ref:`module_only_additional` + * :ref:`module_only` + +.. _partial_installation_stop: + +Stopping the installation procedure *after* a step using ``-s``/``--stop`` +-------------------------------------------------------------------------- + +To stop the installation procedure *after* a specific step in the installation procedure, the ``-s``/``--stop`` +command line option can be used; the name of the step must be supplied as an argument. + +The following step names are recognized (listed in execution order): ``fetch``, ``ready``, ``source``, ``patch``, +``prepare``, ``configure``, ``build``, ``test``, ``install``, ``extensions``, ``package``, ``postproc``, +``sanitycheck``, ``cleanup``, ``module``, ``testcases``. + +Example usage:: + + $ eb GCC-4.9.2.eb --stop configure + == temporary log file in case of crash /tmp/eb-X2Z0b7/easybuild-mGxmNb.log + == processing EasyBuild easyconfig /home/example/GCC-4.9.2.eb + == building and installing GCC/4.9.2... + == fetching files... + == creating build dir, resetting environment... + == unpacking... + == patching... + == preparing... + == configuring... + == COMPLETED: Installation STOPPED successfully + == Results of the build can be found in the log file /dev/shm/example/GCC/4.9.2/dummy-dummy/easybuild/easybuild-GCC-4.9.2-20150430.091644.log + == Build succeeded for 1 out of 1 + == temporary log file(s) /tmp/eb-X2Z0b7/easybuild-mGxmNb.log* have been removed. + == temporary directory /tmp/eb-X2Z0b7 has been removed. + + +.. _partial_installation_skip: + +Installing additional extensions using ``-k``/``-skip`` +------------------------------------------------------- + +For software applications that may include :ref:`extensions`, it is often required to install one or more additional +extensions without having to reinstall the software package (and all extensions) from scratch. +For this purpose, the ``-k``/``--skip`` command line option is available. + +To actually skip an existing software installation and all installed extensions, a corresponding module must be +available already; if not, the installation procedure will be performed from scratch. +To trigger the installation of missing extensions, ``--force`` must be used as well; without it, the installation +procedure will be skipped as a whole (since the module is already available). + +When ``--skip`` is combined with ``--force``, EasyBuild will: + +i) ensure that all (extension) sources are available (and try to fetch them if needed); +ii) prepare the build environment; +iii) check which extensions have not been installed yet; +iv) install the missing extensions; +v) run the sanity check (which includes checking that all extensions are available) +vi) regenerate the module file (since it contains a list of installed extensions) + +Example usage:: + + $ eb Python-2.7.9-intel-2015a.eb --skip + ... + == Python/2.7.9-intel-2015a is already installed (module found), skipping + == No easyconfigs left to be built. + == Build succeeded for 0 out of 0 + +.. code:: + + $ eb Python-2.7.9-intel-2015a.eb --skip --force + ... + == building and installing Python/2.7.9-intel-2015a... + ... + == configuring [skipped] + == building [skipped] + == testing [skipped] + == installing [skipped] + == taking care of extensions... + ... + == sanity checking... + == cleaning up... + == creating module... + == COMPLETED: Installation ended successfully + +.. note:: + Upgrading of extensions to a newer version does not work (yet) using ``--skip``, because the way in which extensions + are checked for availability, i.e. the extensions filter, is (usually) version-agnogstic. + +.. note:: + The '``skipsteps``' easyconfig parameter has a different purpose, i.e. to specify which installation steps should + *always* be skipped when the installation of a particular software package is performed, no matter whether the + software or corresponding module is already available or not. + +.. _module_only: + +Only (e)generating (additional) module files using ``--module-only`` +--------------------------------------------------------------------- + +Since EasyBuild v2.1, it is possible to only (re)generate the module file that matches the specifications in the +easyconfig file, using ``--module-only``. Depending on the use case, additional options should be supplied. + +Usually ``--force`` is also required, either to ignore the existing module file (if the module is available under the +same name as the one being (re)generated), or to skip the sanity check that verifies the software installation (if no +software installation is available). + +Combining ``--module-only`` with ``--installpath-modules`` is also a common use case, to generate the module file in +a (test) location other than the software installation prefix (see :ref:`installpath`). + +Use cases: + +* :ref:`module_only_only_regenerate` +* :ref:`module_only_existing_different` +* :ref:`module_only_force` + +.. _module_only_only_regenerate: + +Only (re)generating (existing) module file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To only generate a module file (i.e., skip actually building and installing the software), or to regenerate an +existing module file, ``--module-only`` can be used. + +In the former case, enabling ``--force`` is required because the sanity check step that verifies whether the +installation produced the expected files and/or directories is not skipped unless forced. +In the latter case, ``--force`` must be used to make EasyBuild ignore that the module is already available +according to the modules tool. + +Example usage: + +* only generate module file:: + + $ module avail GCC + ---------------------------- /home/example/.local/modules/all ---------------------------- + GCC/4.8.2 + + $ eb GCC-5.1.0.eb --module-only --force + ... + == building and installing GCC/5.1.0... + == fetching files [skipped] + ... + == configuring [skipped] + == building [skipped] + == testing [skipped] + == installing [skipped] + ... + == sanity checking [skipped] + == cleaning up [skipped] + == creating module... + == COMPLETED: Installation ended successfully + ... + + $ module avail GCC + + ---------------------------- /home/example/.local/modules/all ---------------------------- + GCC/4.8.2 GCC/5.1.0 + +* regenerate existing module file:: + + $ module avail GCC/4.8.2 + + ---------------------------- /home/example/.local/modules/all ---------------------------- + GCC/4.8.2 + + $ ls -l /home/example/.local/modules/all/GCC/4.8.2 + -rw-rw-r-- 1 example example 1002 Jan 11 17:19 /home/example/.local/modules/all/GCC/4.8.2 + + $ eb GCC-4.8.2.eb --module-only --force + ... + == building and installing GCC/4.8.2... + ... + == sanity checking [skipped] + == creating module... + == COMPLETED: Installation ended successfully + ... + + $ ls -l /home/example/.local/modules/all/GCC/4.8.2 + -rw-rw-r-- 1 example example 1064 Apr 30 10:54 /home/example/.local/modules/all/GCC/4.8.2 + +.. _module_only_additional: + +Generating additional module files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Generating an additional module file, next to the one(s) already available, is also supported. This can achieved by +combining ``--module-only`` with additional configuration options that apply to the module generation. + +Examples: + +* to generate a module file in Lua syntax, next to an already existing module file in Tcl syntax, + ``--module-only --module-syntax=Lua`` can be used:: + + $ module avail GCC/4.8.2 + + ---------------------------- /home/example/.local/modules/all ---------------------------- + GCC/4.8.2 + + $ ls -l /home/example/.local/modules/all/GCC/4.8.2* + -rw-rw-r-- 1 example example 1064 Apr 30 10:54 /home/example/.local/modules/all/GCC/4.8.2 + + $ eb GCC-4.8.2.eb --modules-tool=Lmod --module-only --module-syntax=Lua --force + ... + == building and installing GCC/4.8.2... + ... + == sanity checking [skipped] + == creating module... + == COMPLETED: Installation ended successfully + ... + + $ ls -l /home/example/.local/modules/all/GCC/4.8.2* + -rw-rw-r-- 1 example example 1064 Apr 30 10:54 /home/example/.local/modules/all/GCC/4.8.2 + -rw-rw-r-- 1 example example 1249 Apr 30 11:56 /home/example/.local/modules/all/GCC/4.8.2.lua + + .. note:: + Since only Lmod can consume module files in Lua syntax, it must be used as a modules tool; + see also :ref:`module_syntax`. + + Only changing the syntax of the module file does not affect the module name, so Lmod will + report the module as being available. Hence, ``--force`` must be used here as well. + +* to generate a module file using a different naming scheme, ``--module-only`` can be combined with + ``--module-naming-scheme``:: + + $ eb --installpath-modules=$HOME/test/modules --module-only --module-naming-scheme=HierarchicalMNS --force + ... + == building and installing Core/GCC/4.8.2... + ... + == sanity checking [skipped] + == creating module... + == COMPLETED: Installation ended successfully + + $ module unuse $HOME/.local/modules/all + $ module use $HOME/test/modules/all + $ module avail + + ---------------------------- /home/example/test/modules/all ---------------------------- + Core/GCC/4.8.2 + + .. note:: Modules that are generated used different module naming schemes should *never* be mixed, hence the use + of ``--installpath-modules``, see also :ref:`installpath_direct_options`. + + .. note:: The modules files generated using the specified module naming scheme will most likely **not** be tied to + an existing software installation in this case (unless the software installation was already there somehow), + since the name of the subdirectory of the software installation prefix is also governed by the active + module naming scheme. This is also why ``--force`` must be used in the example above (to skip the sanity + check that verifies the software installation). + + Thus, this is only useful to assess how the module tree would look like under a particular module naming + scheme; the modules themselves are useless since they point to empty installation directories. + + To tie a module file generated using to an existing software installation that was performed under a + different module naming scheme, a simple module naming scheme can be implemented that mixes two modules + naming schemes, by providing the name of the software installation subdirectory using one scheme, and the + module names (and other metadata for module files) with the other. + + See for example the `MigrateFromEBToHMNS module naming scheme that is used by the EasyBuild framework unit + tests `_. diff --git a/docs/Release_notes.rst b/docs/Release_notes.rst index b0a5f1cd..bbb77183 100644 --- a/docs/Release_notes.rst +++ b/docs/Release_notes.rst @@ -3,9 +3,161 @@ EasyBuild release notes ======================= -The latest version of EasyBuild provides support for building and installing **581** different software packages, -using 32 different (compiler) toolchains. It contains 143 software-specific easyblocks and 21 generic easyblocks, -alongside 3,344 easyconfig files. +The latest version of EasyBuild provides support for building and installing **608** different software packages, +using 33 different (compiler) toolchains. It contains 145 software-specific easyblocks and 22 generic easyblocks, +alongside 3,618 easyconfig files. + +v2.1.0 (April 30th 2015) +------------------------ + +feature + bugfix release + +**framework** + +* requires vsc-base v2.2.0 or more recent + + * added support for LoggedException (`vsc-base#160 `_, `vsc-base#163 `_, `vsc-base#165 `_, `vsc-base#167 `_) + * added support for add_flex action in GeneralOption (`vsc-base#162 `_) + * added support to GeneralOption to act on unknown configuration environment variables (`vsc-base#162 `_) + +* add support for only (re)generating module files: ``--module-only`` (`#1018 `_) + + * module naming scheme API is enhanced to include det_install_subdir method + * see :ref:`module_only` + +* add support for generating module files in Lua syntax (note: requires Lmod as modules tool) (`#1060 `_, `#1255 `_, `#1256 `_, `#1270 `_) + + * see ``--module-syntax`` configuration option and :ref:`module_syntax` + +* deprecate ``log.error`` method in favor of raising ``EasyBuildError`` exception (`#1218 `_) + + * see :ref:`depr_error_reporting` + +* add support for using external modules as dependencies, and to provide metadata for external modules (`#1230 `_, `#1265 `_, `#1267 `_) + + * see :ref:`using_external_modules` + +* add experimental support for Cray toolchains on top of PrgEnv modules: ``CrayGNU``, ``CrayIntel``, ``CrayCCE`` (`#1234 `_, `#1268 `_) + + * see https://github.com/hpcugent/easybuild/wiki/EasyBuild-on-Cray + +* various other enhancements, including: + + * clear list of checksums when using ``--try-software-version`` (`#1169 `_) + * sort the results of searching for files (e.g., ``--search`` output) (`#1214 `_) + * enhance test w.r.t. use of templates in cfgfile (`#1217 `_) + * define '``%(DEFAULT_REPOSITORYPATH)s``' template for cfgfiles (see ``eb --avail-cfgfile-constants``) (`#1220 `_) + * also reset ``$LD_PRELOAD`` when running module commands, in case module defined ``$LD_PRELOAD`` (`#1222 `_) + * move location of '``module use``' statements in generated module file (*after* '``module load``' statements) (`#1232 `_) + * add support for ``--show-default-configfiles`` (`#1240 `_) + + * see :ref:`default_configuration_files` + + * report error on missing configuration files, rather than ignoring them (`#1240 `_) + * clean up commit message used in easyconfig git repository (`#1248 `_) + * add ``--hide-deps`` configuration option to specify names of software that must be installed as hidden modules (`#1250 `_) + + * see :ref:`hide_deps` + + * add support for appending/prepending to ``--robot-paths`` to avoid overwriting default robot search path (`#1252 `_) + + * see :ref:`robot_search_path_prepend_append` + + * enable detection of use of unknown ``$EASYBUILD``-prefixed environment variables (`#1253 `_) + + * see :ref:`configuration_env_vars` + + * add ``--installpath-modules`` and ``--installpath-software`` configuration options (`#1258 `_) + + * see :ref:`installpath` + + * use dedicated subdirectory in temporary directory for each test to ensure better cleanup (`#1260 `_) + * get rid of ``$PROFILEREAD`` hack when running commands, not needed anymore (`#1264 `_) + +* various bug fixes, including: + + * make bootstrap script robust against having ``vsc-base`` already available in Python search path (`#1212 `_, `#1215 `_) + * set default value for unpack_options easyconfig parameter to ``''``, so ``self.cfg.update`` works on it (`#1229 `_) + * also copy rotated log files (`#1238 `_) + * fix parsing of ``--download-timeout`` value (`#1242 `_) + * make ``test_XDG_CONFIG_env_vars`` unit test robust against existing user config file in default location (`#1259 `_) + * fix minor robustness issues w.r.t. ``$XDG_CONFIG*`` and ``$PYTHONPATH`` in unit tests (`#1262 `_) + * fix issue with handling empty toolchain variables (`#1263 `_) + +**easyblocks** + +* replace '``log.error``' with '``raise EasyBuildError``' in all easyblocks (`#588 `_) +* one new generic easyblock: ``ConfigureMakePythonPackage`` (`#540 `_) +* new easyblocks for 2 software packages that require customized support: + + * TINKER (`#578 `_), Xmipp (`#581 `_) + +* various other enhancements, including: + + * enhance WIEN2k easyblock for recent versions + cleanup (`#486 `_) + * define ``$PYTHONNOUSERSITE`` in PythonPackage easyblock so user-installed packages are not picked up (`#577 `_) + * add support in CP2K easyblock for building on top of MPICH/MPICH2 (`#579 `_) + * enhance Hadoop easyblock to support parallel builds (`#580 `_) + * drop ``-noroot`` for recent FLUENT versions, honor ``installopts``, enable ``-debug`` (`#582 `_) + * include ``prebuildopts`` in build command for Python packages (`#585 `_) + * also install ``rosetta_tools`` subdirectory for Rosetta (`#586 `_) + * update SLEPc easyblock for v3.5 + style cleanup (`#593 `_) + * minor fix in HPL easyblock w.r.t. checking defined environment variables (`#595 `_) + * tweak CP2K easyblock w.r.t. LAPACK/FFTW support (`#596 `_) + * minor update to GCC easyblock to support GCC v5.x (`#598 `_) + * update sanity check in R easyblock for version 3.2.0 (`#602 `_) + +* various bug fixes, including: + + * fix Score-P easyblock for compiler-only toolchains, include Qt as optional dependecy (`#552 `_) + * fix definition of ``$MKLROOT``, should be set to '``mkl``' subdir of install dir (`#576 `_) + * add ``-libmpichf90`` to list of MPI libraries in NWChem easyblock (`#584 `_) + * stop using '``$root``' to make easyblocks compatible with module files in Lua syntax (`#590 `_) + * also set ``$PYTHONPATH`` before installing Python package in temporary directory in ``test_step`` (`#591 `_) + * unset ``buildopts``/``installopts`` before installing Python extensions in Python easyblock (`#597 `_) + * allow not including vsc-base sources when installing EasyBuild (gets installed with easybuild-framework) (`#600 `_) + * use ``self.initial_environ`` rather than ``self.orig_environ`` in EasyBuildMeta easyblock (`#600 `_) + * make GCC easyblock compatible with ``--module-only`` by setting default value for ``self.platform_lib`` in constructor (`#603 `_) + + +**easyconfigs** + +* added example easyconfig files for 27 new software packages: + + * AFNI (`#1322 `_, `#1521 `_), BCFtools (`#1492 `_), getdp (`#1518 `_), gmsh (`#1518 `_), gtest (`#1244 `_), hanythingondemand (`#1530 `_), mawk (`#1369 `_), Minimac (`#815 `_), Minimac3 (`#1502 `_), monty (`#1548 `_), Octave (`#1563 `_), pbs_python (`#1530 `_), pigz (`#1036 `_), Pygments (`#1536 `_), pyhull (`#1539 `_), pymatgen (`#1549 `_), PyQt (`#1322 `_, `#1521 `_), Ray (`#1494 `_), requests (`#1536 `_), seqtk (`#1524 `_), SIP (`#1322 `_, `#1521 `_), S-Lang (`#1369 `_), Spark (`#1554 `_), spglib (`#1549 `_), TINKER (`#1465 `_), tmux (`#1369 `_), Xmipp (`#1489 `_) + +* added easyconfigs for new (Cray-specific) toolchains (`#1538 `_): ``CrayGNU``, ``CrayIntel``, ``CrayCCE`` + + * initially supported software (using CrayGNU toolchains): CP2K, GROMACS, HPL, Python + numpy/scipy, WRF (`#1558 `_) + * see also https://github.com/hpcugent/easybuild/wiki/EasyBuild-on-Cray + +* added new easyconfigs for existing toolchains: ``goolf/1.5.16``, ``intel/2014.06`` +* added additional easyconfigs for various supported software packages: version updates, different toolchains, ... + + * including GCC v5.1.0, OpenFOAM v2.3.1, R v3.1.3 and v3.2.0, PETSc/SLEPc v3.5.3, WIEN2k v14.1 + +* various other enhancements, including: + + * include pbr dependency for lockfile Python extension in Python v2.7.9 easyconfigs + mock/pytz/pandas (`#1462 `_, `#1540 `_) + * include SQLite as dependency in Python v2.7.9 easyconfigs (`#1468 `_) + * set ``$LD_PRELOAD`` for Hoard and jemalloc (`#1470 `_) + * fix homepage in SCOTCH easyconfigs (`#1485 `_) + * adding missing six/ecdsa dependencies for dateutil/paramiko Python packages in Python easyconfigs (`#1504 `_, `#1505 `_, `#1506 `_, `#1507 `_, `#1508 `_, `#1509 `_, `#1510 `_) + * enable ``pic`` toolchain option in expat easyconfigs (`#1562 `_) + * extend list of source URLs for Bioconductor packages in R easyconfigs to include 'release' source URLs (`#1568 `_) + +* various bug fixes, including: + + * adding missing zlib dependency in all Tcl easyconfig files (`#1344 `_) + * fix homepage in FLUENT easyconfigs (`#1472 `_) + * use ``--with-verbs`` rather than deprecated ``--with-openib`` in OpenMPI configure options (`#1511 `_) + * stop relying on ``OS_NAME`` constant to specify OS dependencies in OpenMPI easyconfigs (`#1512 `_) + * replace use of '``$root``' with '``%(installdir)s``' to ensure compatibility with module files in Lua syntax (`#1532 `_) + * stop relying on '``$MKLROOT``' in ROOT easyconfigs (`#1537 `_) + * use proper Bundle easyblock for biodeps/PRACE (`#1566 `_) + * make source_urls in Cube and Scalasca easyconfigs compatible with --try-software-version (`#1574 `_) + * add patch for Cube to fix configure script w.r.t. Qt dependency, add --without-java-reader configure option (`#1574 `_) + v2.0.0 (March 6th 2015) ----------------------- diff --git a/docs/Using_external_modules.rst b/docs/Using_external_modules.rst new file mode 100644 index 00000000..27e0642a --- /dev/null +++ b/docs/Using_external_modules.rst @@ -0,0 +1,106 @@ +.. _using_external_modules: + +Using external modules +====================== + +Since EasyBuild v2.1, support for using modules that were not installed via EasyBuild is available. +We refer to such modules as *external modules*. + +This can be useful to reuse vendor-supplied modules, for example on Cray systems. + + +Using external modules as dependencies +--------------------------------------- + +External modules can be used as dependencies, by including the module name in the ``dependencies`` list (see +:ref:`dependency_specs`), along with the ``EXTERNAL_MODULE`` constant marker. + +For example, to specify the readily available module ``fftw/3.3.4.2`` as a dependency:: + + dependencies = [('fftw/3.3.4.2', EXTERNAL_MODULE)] + +For such dependencies, EasyBuild will: + +* load the module before initiating the software build and install procedure +* include a '``module load``' statement in the generated module file (for non-build dependencies) + +If the specified module is not available, EasyBuild will exit with an error message stating that the dependency can +not be resolved because the module could not be found. It will *not* search for a matching easyconfig file in order to +try and install the module to resolve the dependency. + + +Metadata for external modules +----------------------------- + +Since very little information is available for external modules based on the dependency specification alone (i.e., only +the module name), metadata can be supplied to EasyBuild for external modules. + +Using the ``--external-modules-metadata`` configuration option, the location of one or more files can be specified that +provide such metadata. The files are expected to be in INI format, with a section per module name and key-value +assignments denoting the metadata specific to that module. + +Format:: + + [modulename] + key1 = value1 + key2 = value2, value3 + +For example, the following file provides metadata for a handful of modules that may be provided on Cray systems:: + + [cray-hdf5/1.8.13] + name = HDF5 + version = 1.8.13 + prefix = HDF5_DIR + + [cray-hdf5-parallel/1.8.13] + name = HDF5 + version = 1.8.13 + prefix = /opt/cray/hdf5-parallel/1.8.13/GNU/49 + + [cray-netcdf/4.3.2] + name = netCDF, netCDF-Fortran + version = 4.3.2, 4.3.2 + prefix = NETCDF_DIR + + +The following keys are supported: + +* ``name``: specifies the software name(s) that is (are) provided by the module +* ``version``: specifies the software version(s) that is (are) provided by the module +* ``prefix``: specifies the installation prefix of the software that is provided by the module, or the name of an + environment variable defined by the module that contains the installation prefix + +Any other keys are simply ignored. + +.. note:: + When both ``name`` and ``version`` are specified, they must provide an *equal number of values* + (see for example the ``cray-netcdf`` example above). + +Using the provided metadata, EasyBuild will define environment variables that are also defined by modules that are +generated by EasyBuild itself. In particular, for each software name that is specified: + +* the corresponding environment variable ``$EBROOT`` is defined to the specified ``prefix`` value (if any) +* the corresponding environment variable ``$EBVERSION`` is defined to the corresponding ``version`` value (if any) + +For example, for the external modules for which metadata is provided in the example above, the following +environment variables are set in the build environment when the module is used as a dependency: + +* for ``cray-hdf5/1.8.1.13``: + + * ``$EBROOTHDF5`` = ``$HDF5_DIR`` + * ``$EBVERSIONHDF5`` = ``1.8.13`` + +* for ``cray-hdf5-parallel/1.8.13``: + + * ``$EBROOTHDF5`` = ``/opt/cray/hdf5-parallel/1.8.13/GNU/49`` + * ``$EBVERSIONHDF5`` = ``1.8.13`` + +* for ``cray-netcdf/4.3.2``: + + * ``$EBROOTNETCDF`` = ``$NETCDF_DIR`` + * ``$EBROOTNETCDFMINFORTRAN`` = ``$NETCDF_DIR`` + * ``$EBVERSIONNETCDF`` = ``4.3.2`` + * ``$EBVERSIONNETCDFMINFORTRAN`` = ``4.3.2`` + +The ``get_software_root`` and ``get_software_version`` functions that are commonly used occasionally in easyblocks +pick up the ``$EBROOT*`` and ``$EBVERSION*`` environment variables, respectively. diff --git a/docs/Using_the_EasyBuild_command_line.rst b/docs/Using_the_EasyBuild_command_line.rst index 9d9854c8..70cbfbf0 100644 --- a/docs/Using_the_EasyBuild_command_line.rst +++ b/docs/Using_the_EasyBuild_command_line.rst @@ -25,10 +25,10 @@ This can be done in a number of ways: Whenever EasyBuild searches for easyconfig files, it considers a couple of locations, i.e. (in order of preference): -(i) the local working directory -(ii) the robot search path (see :ref:`robot_search_path`) +(i) the local working directory +(ii) the robot search path (see :ref:`robot_search_path`) (iii) the path to easyconfig files that are part of the active EasyBuild installation - (which is included in the default robot search path) + (which is included in the default robot search path) These locations are only considered for easyconfig files that are specified only by filename or using a relative path, *not* for easyconfig files that are specified via an absolute path. @@ -447,7 +447,8 @@ These two configuration options each serve a particular purpose, and together de * does *not* enable the dependency resolution mechanism * the specified list of paths is included *last* in the robot search path * by default, only the path to the easyconfig files that are part of the EasyBuild installation is listed - * **note**: setting this configuration option implies redefining the default robot search path! + * **note**: setting this configuration option implies redefining the default robot search path, unless a + prepending/appending list of paths is specified, see :ref:`robot_search_path_prepend_append` For both options, the list of paths should be specified as a colon-separated (``:``) list. @@ -474,6 +475,23 @@ For more information on using constants in EasyBuild configuration files, see specified for ``--robot-paths``, on any configuration level, and vice versa. For more information on the relation between the different configuration types, see :ref:`configuration_types`. +.. _robot_search_path_prepend_append: + +Prepending and/or appending to the default robot search path +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +Prepending or appending to the default robot search path is supported via the ``--robot-paths`` configuration option. + +To *prepend* one or more paths, a list of paths followed by a '``:``' should be specified. + +Analogously, to *append* one or more paths, a list of paths preceded by a '``:``' should be specified. + +For example: + +* ``export EASYBUILD_ROBOT_PATHS=/tmp/$USER:`` specifies to prepend ``/tmp/$USER`` to the robot search path +* ``--robot-paths :$HOME/eb:$HOME/test`` specifies to append ``$HOME/eb`` and ``$HOME/test`` to the robot search path (in that order) +* ``--robot-paths=/tmp/$USER::$HOME/test`` specifies to prepend ``/tmp/$USER`` *and* append ``$HOME/test`` to the robot search path + Example use case ++++++++++++++++ diff --git a/docs/Writing_easyconfig_files.rst b/docs/Writing_easyconfig_files.rst index 7dcd8bfe..f583e4b2 100644 --- a/docs/Writing_easyconfig_files.rst +++ b/docs/Writing_easyconfig_files.rst @@ -146,7 +146,7 @@ Dependencies * **dependencies**: build/runtime dependencies * **builddependencies**: build-only dependencies (not in module) -* **hiddendependencies**: dependencies via hidden modules +* **hiddendependencies**: dependencies via hidden modules (see also :ref:`hide_deps`) * **osdependencies**: system dependencies (package names) Remarks: @@ -198,6 +198,12 @@ which is equivalent to:: dependencies = [('PnMPI', '1.2.0', '', True)] +Using external modules as dependencies +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Since EasyBuild v2.1, specifying modules that are not provided via EasyBuild as dependencies is also supported. +See :ref:`using_external_modules` for more information. + .. _configure_build_install_command_options: Configure/build/install command options diff --git a/docs/conf.py b/docs/conf.py index 62bce78d..b4aa7808 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -41,9 +41,9 @@ # other places throughout the built documents. # # The short X.Y version. -version = '2.0.0' # this is meant to reference the version of EasyBuild +version = '2.1.0' # this is meant to reference the version of EasyBuild # The full version, including alpha/beta/rc tags. -release = '20150327.01' # this is meant to reference the version of the documentation itself +release = '20150430.01' # this is meant to reference the version of the documentation itself # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: diff --git a/docs/index.rst b/docs/index.rst index 3e60597e..2cb13b74 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -55,6 +55,9 @@ Advanced usage topics :maxdepth: 3 Integration_with_GitHub + Manipulating_dependencies + Partial_installations + Using_external_modules Other topics ============