1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
|
Version 0.14.0
* Support for configuration types, configuration linking, and build-time
dependencies.
Configurations can now be linked with each other to allow a package to be
built in one configuration while its dependencies in one or more linked
configurations. This can be used to create a "base" configuration with
common dependencies that are shared between multiple configurations.
Configurations now also have types with the three predefined types being
`target` (the default) `host` (used for build-time project packages and/or
dependencies), and `build2` (used for build system modules). We can now
also have multiple default configurations provided they are of different
types. This mechanism together with configuration linking is used to
provide separate configurations for build-time dependencies, for example,
tools that need to be executed or build system modules that need to be
loaded during the build.
If during initialization or synchronization a build-time dependency is
encountered and there is no build configuration of a suitable type
associated with the project, then the user is prompted to automatically
create such a configuration and associate it with the project.
New relevant commands: bdep-config-{link,unlink}.
Command with relevant changes (new options, etc): bdep-config-create,
bdep-init, bdep-sync.
See bdep-config(1) and bdep-sync(1) for details of this functionality.
See also the corresponding functionality in bpkg on which this is built.
* Project packages are now by default initialized for development.
Specifically, a package is configured with config.<package>.develop=true
unless an alternative value is specified on the command line. For example:
$ bdep init @install config.hello.develop=false
To change the development mode of an already initialized package, use
bdep-sync:
$ bdep sync @install config.hello.develop=false
See the build system manual for details on the config.*.develop variables.
* Configuration of project packages is now preserved during synchronization.
To reconfigure a package from scratch, use the new --disfigure bdep-sync
option. For example:
$ bdep sync config.hello.develop=false
$ bdep sync # develop=false
$ bdep sync --disfigure # develop=true
* The bdep-new command can now create multi-language C/C++ projects.
* The bdep-new command can now create binless (header-only) C libraries.
* The bdep-new command now generates smarter glue buildfile that reads
packages.manifest instead of using a directory wildcard.
* New --immediate|-i and --recursive|-r bdep-{update,clean} options.
These options can be used to additionally updating or cleaning immediate
or all dependencies of the project packages, respectively.
* New --build-config bdep-ci option.
This option provides an easier way to specify the desired build
configuration or configuration pattern.
* New --interactive|-i bdep-ci option.
This option can be used to request an interactive CI session. In this mode
the CI service pauses the testing at the specified breakpoint and provides
the login information for the execution environment.
* Support for argument grouping in bdep-{sync,init}.
See bdep-argument-grouping(1) for details on argument grouping.
* New BDEP_DEF_OPT environment variable that can be used to suppress loading
of default options files.
Version 0.13.0
* The SPDX License Expression in now the default scheme in the bdep-new
--type|-t,license sub-option.
Auto-detected licenses now also result in the SPDX License ID in the
'license' package manifest value.
* New source layout customization mechanisms in bdep-new.
In particular, the split include/src layout is now supported out of the
box:
$ bdep new -l c++ -t lib,split libhello
See the SOURCE LAYOUT section in bdep-new(1) for details and a large
number of examples.
* The bdep-new command in the --package mode now creates the "glue
buildfile" for the project.
* The bdep-new command now generates the .gitattributes file with sensible
defaults.
* The bdep-new --subdirectory mode option has been renamed to --source.
The corresponding default options file has also been renamed to
bdep-new-source.options.
* The bdep-new binless sub-option has been moved from --lang|-l to --type|t.
Version 0.12.0
* Support for creating new projects with existing files.
The bdep-new command now also recognizes and handles the following
existing filesystem entries in the project root:
.git -- assume VCS is already initialized and is Git
LICENSE -- try to guess the manifest license from contents
README.md -- try to extract the manifest summary line from contents
Overall, the idea is to streamline the workflow where one creates a
project on one of the hosting services (GitHub, GitLab, etc) and then
initializes it with bdep-new.
Also, to this effect, specifying the project name is now optional and if
omitted, the current working directory (or --output-dir, if specified) is
assumed to be the project name.
An example of this streamlined workflow:
$ # create project with LICENSE and README.md on a Git hosting service
$ git clone .../libhello.git
$ cd libhello
$ bdep new -t lib
Finally, with this change it now makes sense to have support for pre-
creation hooks (--pre-hook) in addition to post-creation (--post-hook).
* Support for default options files (aka tool config files).
See the bdep-default-options-files(1) help topic for background and the
DEFAULT OPTIONS FILES section in each command's man pages for specifics.
* New bdep-new no-install project type sub-option.
In particular, this should be useful when creating *-tests packages.
* The C library projects created by bdep-new are now portable.
Specifically, the use of fmemopen() was replaced with tmpfile().
* The pre and post-creation hooks now make use of portable builtins.
To instead use a system-provided program, prefix the name with `^`, for
example:
$ bdep new --post-hook "^cat --squeeze-blank .../.gitignore >>.gitignore"
See bdep-new(1) for details.
* Ability to specify <pkg-args> in the bdep-init command's -A and -C forms.
* Ability to keep/update/remove the current tag in the bdep-release
command's revision mode.
Note also that previously the default was to update while now it is to
keep.
* Ability to have multiple forwarded configurations.
The new constraint is that such configurations should not have any common
packages (a package's source directory cannot be forwarded to multiple
configurations).
* New bdep-submit --forward option.
This option instructs bdep-submit to use each package's forwarded
configuration in order to prepare the distributions. This helps with
setups where there is no single configuration that has all the packages
(such as a build system module project).
* New bdep-init --no-sync option.
This allows postponing initialization in the build configurations to a
later explicit bdep-sync. One subtle difference with such an explicit sync
is that it will be performed without having the project's database open,
which can be important if the initialization triggers an implicit sync
(via a hook) of a project that uses the same database (as is the case with
build system module projects).
Version 0.11.0
* The bdep-new command now by default adds a README.md template. This can be
suppressed with the new no-readme project type sub-option. For example:
$ bdep new -t exe,no-readme hello
* New license=<name> bdep-new project type sub-option allows specifying a
project license. For example:
$ bdep new -t exe,license=MIT hello
Commonly used license names are 'MIT', 'ASLv2' (Apache License 2.0),
'GPLv3', and 'proprietary' (see the 'license' package manifest value
documentation for a more extensive list of names). Note that if the
license is not specified, the default is now 'proprietary' instead of
'TODO'.
* New bdep-new --post-hook option allows the execution of customization
commands in the newly created project. For example:
$ bdep new --post-hook "echo .idea/ >>.gitignore" hello
See the bdep-new(1) man pages for details.
* The bdep-ci command now allows overriding certain manifest values in
packages being submitted for testing. This is primarily useful for
specifying alternative build configurations and/or build notification
emails. For example:
$ bdep ci --builds gcc
See the bdep-ci(1) man pages for details.
* New bdep-release --amend and --squash options allow releasing a revision
by squashing and amending one or more existing commits.
* New --existing|-e option for bdep-{init,new} --config-create|-C and
bdep-config create modes. With this option bdep initializes a bpkg
configuration based on an existing build system configuration instead of
creating a new one from scratch. For example:
$ b create: build-clang/,cc config.cxx=clang++
$ bdep new -C build-clang --existing hello
Version 0.10.0
* New bdep-new --subdirectory mode.
This mode can be used to create a new source subdirectory in an already
existing project.
* Support for more granular C++ source file extension specification in
bdep-new.
For example:
$ bdep new -t lib -l c++,hxx=h,cxx=cpp libhello # .h & .cpp
$ bdep new -t lib -l c++,extension=?++ libhello # .h++, .c++, etc
See the bdep-new(1) man pages for details.
* Support for suppressing the generation of the library version header.
Specifically, the bdep-new --type|-t=lib option now has the new no-version
sub-option.
* Support for the alternative build file/directory naming scheme.
Specifically, the bdep-new --type|-t option now has the new alt-naming
sub-option that can be used to create projects with the alternative
naming.
* New bdep-release --[no]-edit options.
Now in all the bdep-release modes that perform a commit, if the project's
repository index already contains other changes, then the commit message
is automatically opened for editing unless --no-edit is specified. The
editing of the commit message in the absence of other changes can be
requested with the --edit option.
Version 0.9.0
* New bdep-release command for managing a project's version during release.
This command can be used to automatically change the project's version
from snapshot to release (or the other way around), commit this change,
tag this commit, and push everything to the remote.
See the "Versioning and Release Management" in The build2 Toolchain
Introduction for usage examples as well as the bdep-release(1) man pages
for details.
* New 'binless' option for the bdep-new 'c++' language parameter.
This option allows creation of a simpler buildfile for header-only (and,
in the future, for module-only) libraries. For example:
$ bdep new -l c++,binless ...
* New --jobs|-j option for specifying the number of jobs to perform in
parallel.
* CI requests from the staged toolchain are now by default sent to
ci.stage.build2.org.
* New --no-progress option for suppressing progress indicators.
Version 0.8.0
* New bdep-ci command for submitting package test requests to CI servers.
See the bdep-ci(1) man pages for details.
* New bdep-publish command for publishing packages to archive-based
repositories. See the bdep-publish(1) man pages for details.
* New unit-tests project type option for the bdep-new command.
If specified (-t exe,unit-tests or -t lib,unit-tests) then generate build
infrastructure for unit testing.
* Ability to suppress auto-synchronization via the BDEP_SYNC environment
variable.
If BDEP_SYNC is set, auto-synchronization will only be performed if its
value is true or 1. So to suppress, run:
$ BDEP_SYNC=0 b
Version 0.7.0
* First public release.
|