bdep-projects-configs(1) bdep 0.19.0-a.0.z

# NAME

`bdep-projects-configs` – specifying projects and configurations

# SYNOPSIS

`bdep command [pkg-spec] [cfg-spec] ...`

`cfg-spec = (@cfg-name | --config|-c cfg-dir)... | --all|-a
pkg-spec = (pkg | (--directory|-d pkg-dir))... | prj-spec
prj-spec = --directory|-d prj-dir`

# DESCRIPTION

Most `bdep` commands operate on a project or some of its packages as well as its build configurations. For example, `status` (`bdep-status(1)`) shows the status of one or more project packages in one or more build configurations. While `fetch` (`bdep-fetch(1)`) fetches the list of available to the project dependency packages, again, in one or more build configurations.

Without any `--directory|-d` options specified, the current working directory is assumed to be either the project root directory, the package root directory, or one of the package subdirectories. This is the common `bdep` usage mode where you run it from within your project's source code directories, similar to version control tools such as `git(1)`.

Alternatively, the project or (several) package directories can be specified with the `--directory|-d` options. Additionally, in all the commands except `init`, an initialized project package can be specified as a `pkg` name. Note that `bdep` operates on a single project but potentially multiple packages belonging to said project at a time.

Some `bdep` commands, such as `fetch`, operate on the whole project. If such a command is given a package directory (either as the working directory or with `--directory|-d`), then it automatically determines its project directory and uses that.

Other commands, such as `status`, operate on one or more packages. If such a command is given a project directory, then it automatically determines the list of packages belonging to this project and uses that. Note that what exactly belonging means is command-specific. For most commands it means all the packages initialized in a given build configuration. For `init` (`bdep-init(1)`), however, it means all the packages available in the project (for example, as listed in `packages.manifest`).

A project managed by `bdep` has one or more associated build configurations (see `bdep-config(1)` for details). Some of these configurations, one per the configuration type, can be designated as default and used if no configuration is specified explicitly. So, for example, running `status` without any arguments in the project directory will show the status of all the project packages initialized in the default configurations.

An associated build configuration can be assigned a name in which case we can specify it using the `@cfg-name` notation. For example:

    $ bdep status @gcc @clang

Note to Windows users: a command line argument with leading `@` has a special meaning in PowerShell. To work around this, you can use the alternative `-@gcc` syntax or the `-n gcc` option.

A configuration without a name can be specified as a directory using the `--config|-c` option. Name and directory specifications can be mixed. For example:

    $ bdep status @gcc -c ../builds/clang

Finally, we can use the `--all|-a` option to specify all the build configurations associated with the project.

# BUGS

Send bug reports to the users@build2.org mailing list.