bdep-projects-configs - Man Page

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

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

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. 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.

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

Copyright (c) 2014-2023 the build2 authors.

Permission is granted to copy, distribute and/or modify this document under the terms of the MIT License.

bdep(1), bdep-ci(1), bdep-clean(1), bdep-config(1), bdep-deinit(1), bdep-fetch(1), bdep-init(1), bdep-publish(1), bdep-status(1), bdep-sync(1), bdep-test(1), bdep-update(1).