Here are tables of various options, containing the following information: The option name The scope of the option: global, module or module-set. Options in module or/and module-set scope can also be defined in options sections. Special comments on the purpose and usage of the option. Option name Description async TypeBoolean Default valueTrue Available since1.6 This option enables the asynchronous mode of operation, where the source code update and the build process will be performed in parallel, instead of waiting for all of the source code updates before starting the build process. Related command-line option: colorful-output TypeBoolean Default valueTrue Set this option to false to disable the colorful output of &kdesrc-build;. Note that &kdesrc-build; will not output the color codes to anything but a terminal (such as xterm, &konsole;, or the normal &Linux; console). Related command-line option: disable-agent-check TypeBoolean Default valueFalse If you are using &ssh; to download the &git; sources (such as if you are using the git+ssh protocol), this option controls if &kdesrc-build; will try and make sure that if you are using ssh-agent, it is actually managing some &ssh; identities. This is to try and prevent &ssh; from asking for your pass phrase for every module. Related command-line option: --disable-agent-check, --no-disable-agent-check git-desired-protocol TypeString Default valuegit History informationThis option was added in &kdesrc-build; 1.16. Prior to 20.06 this option was used to configure the fetch URL instead of the push URL. As of 20.06 https is always used when updating KDE projects. This option only applies to modules from a &kde; project repository. What this option actually does is configure which network protocol to prefer when pushing source code for these modules. Normally the very-efficient git protocol is used, but this may be blocked in some networks (e.g. corporate intranets, public Wi-Fi). An alternative protocol which is much better supported is the https protocol used for Internet web sites. If you are using one of these constrained networks you can set this option to http to prefer https communications instead. You may also need the http-proxy option if an HTTP proxy is also needed for network traffic. In any other situation you should not set this option as the default protocol is most efficient. git-repository-base TypeString Available since1.12.1 This option is used to create a short name to reference a specific Git repository base URL in later module set declarations, which is useful for quickly declaring many Git modules to build. You must specify two things (separated by a space): The name to assign to the base URL, and the actual base URL itself. For example: global # other options # This is the common path to all anonymous Git server modules. git-repository-base kde-git kde: end global # Module declarations module-set # Now you can use the alias you defined earlier, but only in a module-set. repository kde-git use-modules module1.git module2.git end module-set The module-set's use-modules option created two modules internally, with &kdesrc-build; behaving as if it had read: module module1 repository kde:module1.git end module module module2 repository kde:module2.git end module The kde: &git; repository prefix used above is a shortcut which will be setup by &kdesrc-build; automatically. See the TechBase URL Renaming article for more information. Note that unlike most other options, this option can be specified multiple times in order to create as many aliases as necessary. It is not required to use this option to take advantage of module-set, this option exists to make it easy to use the same repository across many different module sets. install-environment-driver TypeBoolean Default valueTrue Available since17.08 Install a shell script that can be sourced in a user's profile setup scripts to easily establish needed environment variables to run the Plasma desktop built by &kdesrc-build;. This driver will alter the following files: $XDG_CONFIG_HOME/kde-env-master.sh (normally found at ~/.config/kde-env-master.sh). $XDG_CONFIG_HOME/kde-env-user.sh (normally found at ~/.config/kde-env-user.sh). The kde-env-user.sh is optional. It is intended for user customizations (see the Troubleshooting and Debugging section of the &kde; UserBase for examples of customizable settings), but these settings can be set elsewhere by the user in their existing profile setup scripts. You can disable this feature by setting this option to false, and ensuring that the install-session-driver option is also disabled. &kdesrc-build; will not overwrite your existing files (if present) unless you also pass the --delete-my-settings command-line option. Related command-line option: --install-environment-driver, --no-install-environment-driver install-session-driver TypeBoolean Default valueTrue Available since1.16 If enabled, &kdesrc-build; will try to install a driver for the graphical login manager that allows you to login to your &kdesrc-build;-built &kde; desktop. This driver will alter the following files: ~/.xsession $XDG_CONFIG_HOME/kde-env-master.sh (normally found at ~/.config/kde-env-master.sh). $XDG_CONFIG_HOME/kde-env-user.sh (normally found at ~/.config/kde-env-user.sh). If you maintain your own login driver then you can disable this feature by setting this option to false. If enabled, this feature also enables the install-environment-driver feature. &kdesrc-build; will not overwrite your existing files (if present) unless you also pass the --delete-my-settings command-line option. Related command-line option: --install-session-driver, --no-install-session-driver niceness TypeInteger Default value10 Set this option to a number between 20 and 0. The higher the number, the lower a priority &kdesrc-build; will set for itself, i.e. the higher the number, the "nicer" the program is. Related command-line option: num-cores TypeInteger Default valueDepends on system Available since20.07 This option is defined by &kdesrc-build; (when using kdesrc-build --generate-config), set to be the number of available CPUs (as indicated by the external application nproc). If &kdesrc-build; cannot detect the number of CPUs, this value is set to 4. See for an example of this option's usage. Related command-line option: --num-cores value num-cores-low-mem TypeInteger Default valueDepends on system Available since20.07 This option is defined by &kdesrc-build; (when using kdesrc-build --generate-config), set to be the number of CPUs that is deemed safe for heavyweight or other highly-intensive modules, such as qtwebengine, to avoid running out of memory during the build. The typical calculation is one CPU core for every 2 gigabytes (GiB) of total memory. At least 1 core will be specified, and no more than num-cores cores will be specified. Although this option is intended to support &Qt; modules, you can use it for your any module in the same way that num-cores is used. If &kdesrc-build; cannot detect available memory then this value will be set to 2. Related command-line option: --num-cores-low-mem value persistent-data-file TypeString Available since1.15 Use this option to change where &kdesrc-build; stores its persistent data. The default is to store this data in a file called .kdesrc-build-data, placed in the same directory as the configuration file in use. If the global configuration file is in use, it will be saved to ~/.local/state/kdesrc-build-data ($XDG_STATE_HOME/kdesrc-build-data, if $XDG_STATE_HOME is set). If you have multiple available configurations in the same directory, you may want to manually set this option, so that different configurations do not end up with conflicting persistent data. Related command-line option: --persistent-data-file file ssh-identity-file TypeString Available since1.14.2 Set this option to control which private SSH key file is passed to the ssh-add command when &kdesrc-build; is downloading source code from repositories that require authentication. See also: . use-idle-io-priority TypeBoolean Default valueFalse Available since1.12 Use lower priority for disk and other I/O, which can significantly improve the responsiveness of the rest of the system at the expense of slightly longer running times for &kdesrc-build;. Related command-line option: --use-idle-io-priority, --no-use-idle-io-priority use-inactive-modules TypeBoolean Default valueFalse Allow kdesrc-build to also clone and pull from repositories marked as inactive. Related command-line option: --use-inactive-modules, --no-use-inactive-modules Option name Description binpath TypeString Set this option to set the environment variable PATH while building. You cannot override this setting in a module option. The default value is the $PATH that is set when the script starts. This environment variable should include the colon-separated paths of your development toolchain. The paths ${install-dir}/bin and ${qt-install-dir}/bin are automatically added. You may use the tilde (~) for any paths you add using this option. Related command-line option: --binpath path branch TypeString Default valuemaster Checkout the specified branch instead of the default branch. For most &kde; modules you probably wish to use the branch-group option instead and use this option for case-by-case exceptions. Related command-line option: --branch value branch-group TypeString Available since1.16-pre2 Set this option to a general group from which you want modules to be chosen. For supported &git; module types, &kdesrc-build; will determine the actual branch to use automatically based on rules encoded by the &kde; developers (these rules may be viewed in the kde-build-metadata source repository in your source directory). After a branch is determined that branch is used as if you had specified it yourself using the branch option. This is useful if you're just trying to maintain up-to-date on some normal development track without having to pay attention to all the branch name changes. Note that if you do choose a branch yourself, that it will override this setting. The same is true of other specific branch selection options such as tag. This option only applies to kde-projects &git; modules (the common case). See also . Related command-line option: --branch-group value build-dir TypeString Default value~/kde/build Use this option to change the directory to contain the built sources. There are three different ways to use it: Relative to the &kde; &git; source directory (see the source-dir option). This is the default, and is selected if you type a directory name that does not start with a tilde (~) or a slash (/). Absolute path. If you specify a path that begins with a /, then that path is used directly. For example, /tmp/kde-obj-dir/. Relative to your home directory. If you specify a path that begins with a ~, then the path is used relative to your home directory, analogous to the shell's tilde-expansion. For example, ~/builddir would set the build directory to /home/user-name/builddir. Perhaps surprisingly, this option can be changed per module. Related command-line option: --build-dir path build-when-unchanged TypeBoolean Default valueTrue Control whether &kdesrc-build; always tries to build a module that has not had any source code updates. If set to true, &kdesrc-build; always attempts the build phase for a module, even if the module did not have any source code updates. With this value it will more likely lead to a correct build. If set to false, &kdesrc-build; will only attempt to run the build phase for a module if the module has a source code update, or in other situations where it is likely that a rebuild is actually required. This can save time, especially if you run &kdesrc-build; daily, or more frequently. This feature is provided as an optimization only. Like many other optimizations, there are trade-offs for the correctness of your installation. For instance, changes to the qt or kdelibs modules may cause a rebuild of other modules to be necessary, even if the source code doesn't change at all. Related command-line option: cmake-generator TypeString Default valueUnix Makefiles Specify which generator to use with &cmake;. Currently both Ninja and Unix Makefiles as well as extra generators based on them like Eclipse CDT4 - Ninja are supported. Invalid (unsupported) values are ignored and treated as if unset. Note that if a valid generator is also specified through cmake-options it will override the value for cmake-generator. Related command-line option: --cmake-generator value cmake-toolchain TypeString Specify a toolchain file to use with &cmake;. When a valid toolchain file is configured, &kdesrc-build; will no longer set environment variables automatically. You can use &set-env;, &binpath; and &libpath; to fix up the environment manually if your toolchain file does not work out of the box with &kdesrc-build;. Refer to the overview of standard flags added by &kdesrc-build; for more information. Note that if a valid toolchain is also specified through cmake-options it will override the value for cmake-toolchain. Related command-line option: --cmake-toolchain value cmake-options TypeString Appends to global options for the default buildsystem, overrides global for other buildsystems. Use this option to specify what flags to pass to &cmake; when creating the build system for the module. When this is used as a global option, it is applied to all modules that this script builds. When used as a module option, it is added to the end of the global options. This allows you to specify common &cmake; options in the global section. This option does not apply to qt (which does not use &cmake;). Use configure-flags instead. If a valid generator is specified among the listed options it will override the value of cmake-generator. Invalid (unsupported) generators are ignored and will not be passed to &cmake;. If a valid toolchain file is specified among the listed options it will override the value of cmake-toolchain. Invalid toolchains are ignored and will not be passed to &cmake;. Since these options are passed directly to the &cmake; command line, they should be given as they would be typed into &cmake;. For example: cmake-options -DCMAKE_BUILD_TYPE=RelWithDebInfo Since this is a hassle, &kdesrc-build; takes pains to ensure that as long as the rest of the options are set correctly, you should be able to leave this option blank. (In other words, required &cmake; parameters are set for you automatically) Related command-line option: --cmake-options value compile-commands-export TypeBoolean Default valueTrue Enables the generation of a compile_commands.json via CMake inside the build directory. Related command-line option: --compile-commands-export, --no-compile-commands-export compile-commands-linking TypeBoolean Default valueFalse Enables the creation of symbolic links from compile_commands.json generated via CMake inside the build directory to the matching source directory. Related command-line option: --compile-commands-linking, --no-compile-commands-linking configure-flags TypeString Appends to global options for the default buildsystem, overrides global for other buildsystems. Use this option to specify what flags to pass to ./configure when creating the build system for the module. When this is used as a global-option, it is applied to all modules that this script builds. This option only works for qt. To change configuration settings for KDE modules, see cmake-options. Related command-line option: --configure-flags value custom-build-command TypeString This option can be set to run a different command (other than make, for example) in order to perform the build process. &kdesrc-build; should in general do the right thing, so you should not need to set this option. However it can be useful to use alternate build systems. The value of this option is used as the command line to run, modified by the make-options option as normal. Related command-line option: --custom-build-command value cxxflags TypeString Appends to global options for the default buildsystem, overrides global for other buildsystems. Use this option to specify what flags to use for building the module. This option is specified here instead of with configure-flags or cmake-options because this option will also set the environment variable CXXFLAGS during the build process. Note that for &kde; 4 and any other modules that use &cmake;, it is necessary to set the CMAKE_BUILD_TYPE option to none when configuring the module. This can be done using the cmake-options option. Related command-line option: --cxxflags value dest-dir TypeString Use this option to change the name a module is given on disk. For example, if your module was extragear/network, you could rename it to extragear-network using this option. Note that although this changes the name of the module on disk, it is not a good idea to include directories or directory separators in the name as this will interfere with any build-dir or source-dir options. Related command-line option: --dest-dir path do-not-compile TypeString Use this option to select a specific set of directories not to be built in a module (instead of all of them). The directories not to build should be space-separated. Note that the sources to the programs will still be downloaded. For example, to disable building the codeeditor and minimaltest directories of the syntaxhighlighting framework, you would add do-not-compile codeeditor minimaltest compiling, you would add "do-not-compile juk kscd" to your syntaxhighlighting options. See for an example. Related command-line option: --do-not-compile value git-user TypeString Available since15.09 This option is intended for &kde; developers. If set, it will be used to automatically setup identity information for the &git; source control software for newly downloaded &git; modules (including the vast majority of &kde; modules). Specifically, the user's name and email fields for each new &git; repository are filled in to the values set by this option. The value must be specified in the form User Name <email@example.com>. For instance, a developer named Foo Barbaz with the email address foo@abc.xyz would use: git-user Foo Barbaz <foo@abc.xyz> http-proxy TypeString Available since1.16 This option, if set, uses the specified URL as a proxy server to use for any HTTP network communications (for example, when downloading the KDE project database). In addition, &kdesrc-build; will try to ensure that the tools it depends on also use that proxy server, if possible, by setting the http_proxy environment variable to the indicated server, if that environment variable is not already set. Related command-line option: --http-proxy value directory-layout TypeString Valid valuesflat, invent, metadata Default valueflat This option is used to configure the layout which &kdesrc-build; should use when creating source and build directories. The flat layout will group all modules directly underneath the top level source and build directories. For example, source/extragear/network/telepathy/ktp-text-ui in the metadata layout would be source/ktp-text-ui using the flat layout instead. The invent layout creates a directory hierarchy mirroring the relative paths of repositories on invent.kde.org. For example source/kde/applications/kate in the metadata layout would be source/utilities/kate using the invent layout instead. This layout only affects KDE projects. It is a good choice for people starting out with &kdesrc-build;. Finally, the metadata layout is the same as the old default behaviour. This layout organises KDE projects according to the project paths specified in the project metadata for these modules. This is a good choice if you want a directory layout which tracks with certain KDE processes, but note that this path is therefore not always stable. As a result, &kdesrc-build; may abandon an old copy of the repository and clone a new one for a project due to changes in the project metadata. Related command-line option: --directory-layout value generate-vscode-project-config TypeBoolean Default valueFalse Module setting overrides global Set this option to true to make &kdesrc-build; create VS Code project files (.vscode directory) in the module source directory. The .vscode folder will be created in the project source directory, only if it does not already exist. The configurations will enable the use of LSP, building, debugging, and running the project from within VS Code. The configuration also recommends extensions to install that are useful for working on most KDE projects. Related command-line option: include-dependencies TypeBoolean Default valueTrue Controls if &kdesrc-build; will include known dependencies of this module in its build, without requiring you to mention those dependencies (even indirectly). This option only works for kde-project-based modules, and requires that the metadata maintained by the &kde; developers is accurate for your selected branch-group. This is to support building applications that need versions of &Qt; or &plasma; more recent than supported on common operating systems. Related command-line option: install-after-build TypeString Default valueTrue This option is used to install the package after it successfully builds. You can also use the --no-install command line flag. Related command-line option: --install-after-build, --no-install-after-build install-dir TypeString Default value~/kde/usr This option controls where to install the module after it is built. If you change this to a directory needing root access, you may want to read about the make-install-prefix option as well. Changing this option for specific module allows you to install it to a different directory than where the &kde; Platform libraries are installed, such as if you were using &kdesrc-build; only to build applications. You can use ${MODULE} or $MODULE in the path to have them expanded to the module's name. Related command-line option: libname TypeString Default valueAuto detected Set this option to change the default name of the installed library directory inside ${install-dir} and ${qt-install-dir}. On many systems this is either "lib" or "lib64". Auto-detection is attempted to set the correct name by default, but if the guess is wrong then it can be changed with this setting. Related command-line option: --libname value libpath TypeString Set this option to set the environment variable LD_LIBRARY_PATH while building. You cannot override this setting in a module option. The default value is blank, but the paths ${install-dir}/$LIBNAME and ${qt-install-dir}/$LIBNAME are automatically added. You may use the tilde (~) for any paths you add using this option. Related command-line option: --libpath path log-dir TypeString Use this option to change the directory used to hold the log files generated by the script. Related command-line option: --log-dir path make-install-prefix TypeString Set this variable to a space-separated list, which is interpreted as a command and its options to precede the make install command used to install modules. This is useful for installing packages with &sudo; for example, but please be careful while dealing with root privileges. Related command-line option: --make-install-prefix value make-options TypeString Set this variable in order to pass command line options to the make command. This is useful for programs such as distcc or systems with more than one processor core. Note that not all supported build systems use make. For build systems that use ninja for build (such as the Meson build system), see the ninja-options setting. Related command-line option: --make-options value manual-build TypeBoolean Default valueFalse Set the option value to true to keep the build process from attempting to build this module. It will still be kept up-to-date when updating from &git;. This option is exactly equivalent to the --no-build command line option. manual-update TypeBoolean Default valueFalse Set the option value to true to keep the build process from attempting to update (and by extension, build or install) this module. If you set this option for a module, then you have essentially commented it out. ninja-options TypeString Set this variable in order to pass command line options to the ninja build command. This can be useful to enable verbose output or to manually reduce the number of parallel build jobs that ninja would use. Note that this setting only controls ninja when used by &kdesrc-build;. The &Qt; webengine module uses ninja indirectly, but only officially supports being built by make. In this situation, you can set NINJAFLAGS as a way to have make pass the appropriate flags when it later calls ninja, by using make-options. options qtwebengine # Restrict make and ninja to using no more than 6 separate compile jobs even # when more CPU is available, to avoid running out of memory make-options -j6 NINJAFLAGS=-j6 end options Related command-line option: --ninja-options value override-build-system TypeString Default valueAuto detected Valid valuesKDE, Qt, qmake, generic, autotools, meson Available since1.16 Normally &kdesrc-build; will detect the appropriate build system to use for a module after it is downloaded. This is done by checking for the existence of specific files in the module's source directory. Some modules may include more than one required set of files, which could confuse the auto-detection. In this case you can manually specify the correct build type. Currently supported build types that can be set are: KDE Used to build &kde; modules. In reality it can be used to build almost any module that uses &cmake; but it is best not to rely on this. Qt Used to build the &Qt; library itself. qmake Used to build &Qt; modules that use qmake-style .pro files. generic Used to build modules that use plain Makefiles and that do not require any special configuration. autotools This is the standard configuration tool used for most Free and open-source software not in any of the other categories. meson This is a relatively new tool gaining popularity as a replacement for the autotools and may be required for some non-&kde; modules. Related command-line option: --override-build-system value purge-old-logs TypeBoolean Default valueTrue This option controls whether old log directories are automatically deleted or not. Related command-line option: --purge-old-logs, --no-purge-old-logs qmake-options TypeString Available since1.16 Any options specified here are passed to the qmake command, for modules that use the qmake build system. For instance, you can use the PREFIX=/path/to/qt option to qmake to override where it installs the module. Related command-line option: --qmake-options value qt-install-dir TypeString This option controls where to install qt modules after build. If you do not specify this option, &kdesrc-build; will assume that &Qt; is provided by the operating system. Related command-line option: --qt-install-dir path remove-after-install TypeString Valid valuesnone, builddir, all Default valuenone If you are low on hard disk space, you may want to use this option in order to automatically delete the build directory (or both the source and build directories for one-time installs) after the module is successfully installed. Possible values for this option are: none - Do not delete anything. builddir - Delete the build directory, but not the source. all - Delete both the source code and build directory. Note that using this option can have a significant detrimental impact on both your bandwidth usage (if you use all) and the time taken to compile &kde; software, since &kdesrc-build; will be unable to perform incremental builds. Related command-line option: --remove-after-install value repository TypeString Available since1.10 This option is used to specify the &git; repository to download the source code for the module. &Qt; (and therefore qt) would need this option, as well as various &kde; modules that are in the process of conversion to use &git;. revision TypeString Available since1.16 If this option is set to a value other than 0 (zero), &kdesrc-build; will force the source update to bring the module to the exact revision given, even if options like branch are in effect. If the module is already at the given revision then it will not be updated further unless this option is changed or removed from the configuration. Related command-line option: run-tests TypeBoolean Default valueFalse If set to true, then the module will be built with support for running its test suite, and the test suite will be executed as part of the build process. &kdesrc-build; will show a simple report of the test results. This is useful for developers or those who want to ensure their system is setup correctly. Related command-line option: --run-tests, --no-run-tests set-env TypeString This option accepts a space-separated set of values, where the first value is the environment variable to set, and the rest of the values is what you want the variable set to. For example, to set the variable RONALD to McDonald, you would put in the appropriate section this command: set-env RONALD McDonald This option is special in that it can be repeated without overriding earlier set-env settings in the same section of the configuration file. This way you can set more than one environment variable per module (or globally). source-dir TypeString Default value~/kde/src This option is used to set the directory on your computer to store the &kde; &git; sources at. You may use the tilde (~) to represent the home directory if using this option. Related command-line option: --source-dir path stop-on-failure TypeBoolean Default valueTrue Setting this option to false allows the script to continue execution after an error occurs during the build or install process. Related command-line option: tag TypeString Available since1.16 Use this option to download a specific release of a module. Note: The odds are very good that you do not want to use this option. &kde; releases are available in tarball form from the &kde; download site. Related command-line option: --tag value use-clean-install TypeBoolean Default valueFalse Available since1.12 Set this option to true in order to have &kdesrc-build; run make uninstall directly before running make install. This can be useful in ensuring that there are not stray old library files, &cmake; metadata, etc. that can cause issues in long-lived &kde; installations. However this only works on build systems that support make uninstall. Related command-line option: --use-clean-install, --no-use-clean-install These options do not require any value (except "filter-out-phases"). They are applied if they are presented in a section. Option name Scope Description no-src globalmodulemodule-set Remove update phase. The other phases that were presented will still be processed. Related command-line option: no-install globalmodulemodule-set Remove install phase. The other phases that were presented will still be processed. Related command-line option: no-tests globalmodulemodule-set Remove test phase. The other phases that were presented will still be processed. Related command-line option: --no-tests no-build globalmodulemodule-set Remove build phase. The other phases that were presented will still be processed. Related command-line option: build-only globalmodulemodule-set If had build phase, remove any other phases. Otherwise, remove all phases. Related command-line option: install-only globalmodulemodule-set If had install phase, remove any other phases. Otherwise, remove all phases. Related command-line option: uninstall globalmodulemodule-set If had uninstall phase, remove any other phases. Otherwise, remove all phases. Related command-line option: --uninstall filter-out-phases globalmodulemodule-set Remove those phases that are listed (space separated) in this option. The other phases that were presented will still be processed. Option name Scope Description ignore-modules globalmodule-set TypeString Available since1.16 Note that when specified in global section, &cmd-ignore-modules; cmdline option does not override this, but instead appends. Modules named by this option, which would be chosen by &kdesrc-build; due to a use-modules option, are instead skipped entirely. Use this option when you want to build an entire kde-projects project grouping except for some specific modules. The option value does not necessarily have to name the module directly. Any module that has full consecutive parts of its &kde; projects module path match one of the option values will be ignored, so you can ignore multiple modules this way. For example, an option value of libs would result in both kde/kdegraphics/libs and playground/libs being excluded (though not kde/kdelibs since the full part kdelibs is what is compared). See also . Related command-line option: use-modules module-set TypeString Available since1.12.1 This option allows you to easily specify many different modules to build at the same point in the configuration file. Every identifier passed to this option is internally converted to a &kdesrc-build; module, with a repository option set to the module-set's repository combined with the identifier name in order to setup the final repository to download from. All other options that are assigned in the module-set are also copied to the generated modules unaltered. The order that modules are defined in this option is important, because that is also the order that &kdesrc-build; will process the generated modules when updating, building, and installing. All modules defined in the given module-set will be handled before &kdesrc-build; moves to the next module after the module-set. If you need to change the options for a generated module, simply declare the module again after it is defined in the module-set, and set your options as needed. Although you will change the options set for the module this way, the module will still be updated and built in the order set by the module-set (i.e. you can't reorder the build sequence doing this). The name to use for the module if you do this is simply the name that you passed to use-modules, with the exception that any .git is removed. See and git-repository-base for a description of its use and an example.