-
Notifications
You must be signed in to change notification settings - Fork 13
/
NEWS
2791 lines (1906 loc) · 98.7 KB
/
NEWS
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
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Version 0.16.0
* Support for Objective-C/C++ compilation.
Specifically, the c and cxx modules now provide the c.objc and cxx.objcxx
submodules which can be loaded in order to register the m{}/mm{} target
types and enable Objective-C/C++ compilation in the c and cxx compile
rules. Note that c.objc and cxx.objcxx must be loaded after the c and cxx
modules, respectively, and while the m{}/mm{} target types are registered
unconditionally, compilation is only enabled if the C/C++ compiler
supports Objective-C/C++ for this target platform. Typical usage:
# root.build
#
using cxx
using cxx.objcxx
# buildfile
#
lib{hello}: {hxx cxx}{*}
lib{hello}: mm{*}: include = ($cxx.target.class == 'macos')
Note also that while there is support for linking Objective-C/C++
executables and libraries, this is done using the C/C++ compiler driver
and no attempt to automatically link any necessary Objective-C runtime
(such as -lobjc) is made. For details, refer to "Objective-C Compilation"
and "Objective-C++ Compilation" in the manual.
* Support for Assembler with C Preprocessor (.S) compilation.
Specifically, the c module now provides the c.as-cpp submodule which can
be loaded in order to register the S{} target type and enable Assembler
with C Preprocessor compilation in the c compile rule. For details, refer
to "Assembler with C Preprocessor Compilation" in the manual.
* Support for buildfile importation.
A project can now export buildfiles that can then be imported by other
projects. This mechanism is primarily useful for exporting target type
definitions and ad hoc rules.
Specifically, a project can now place *.build files into its build/export/
subdirectory (or *.build2 and build2/export/ in the alternative naming
scheme). Such files can then be imported by other projects as buildfile{}
targets. For example:
import thrift%buildfile{thrift-cxx}
While for other target types the semantics of import is to load the
project's export stub and return the exported target, for buildfile{} the
semantics is to source the imported buildfile at the point of importation.
Note that care must be taken when authoring exported buildfiles since they
will be sourced by other projects in unpredictable circumstances. In
particular, the import directive by default does not prevent sourcing the
same buildfile multiple times (neither in the same project nor in the same
scope). As a result, if certain parts must only be sourced once per
project (such as target type definitions), then they must be factored into
a separate buildfile (in build/export/) that is imported by the "main"
exported buildfile with the `once` attribute. For example, the above
thrift-cxx.build may contain:
import [once] thrift%buildfile{thrift-cxx-target-type}
See also "install Module" in the manual for details on the exported
buildfile installation.
* Support for defining explicit (as opposed to ad hoc) target groups.
A user-defined explicit target group must be derived from the group base
target type. If desired, it can be marked as "see-through", meaning that
when it is listed as a prerequisite of a target, the matching rule will
"see" its members, rather than the group itself. For example:
define [see_through] thrift_cxx: group
define thrift: file
thrift{*}: extension = thrift
exe{hello}: cxx{hello} thrift_cxx{data}
thrift_cxx{data}: thrift{data}
Explicit group members can be specified statically, injected by an ad hoc
rule, or extracted dynamically by the depdb-dyndep builtin (see the next
NEWS item). For example:
thrift_cxx{data}<{hxx cxx}{data_constants}>: thrift{data} # Static.
thrift_cxx{~'/(.+)/'}<{hxx cxx}{^'/\1_types/'}>: thrift{~'/\1/'} # Inject.
{{
depdb dyndep --dyn-target ... # Dynamic.
}}
* Support for dynamic target extraction in addition to prerequisites.
This functionality is enabled with the depdb-dyndep --dyn-target option.
If the recipe target is an explicit group (see the previous NEWS item),
then the dynamically extracted targets are added as its members.
Otherwise, the listed targets are added as ad hoc group members. In both
cases the dynamically extracted target is ignored if it is already
specified as a static member or injected by a rule. Note that this
functionality is not available in the --byproduct mode. See the
depdb-dyndep builtin options description for details.
* New `lines` depdb-dyndep dependency format in addition to `make`.
The `lines` format lists targets and/or prerequisites one per line. See
the depdb-dyndep builtin options description for details.
* Low verbosity diagnostics rework.
The low verbosity (level 1) rule diagnostics format has been adjusted to
include the output target where appropriate. The implementation has also
been redesigned to go through the uniform print_diag() API, including for
the `diag` pseudo-builtin in ad hoc recipes.
Specifically, the `diag` builtin now expects its arguments to be in one of
the following two forms (which correspond to the two print_diag() forms):
diag <prog> <l-target> <comb> <r-target>...
diag <prog> <r-target>...
If the `diag` builtin is not specified, the default diagnostics is now
equivalent to:
For update:
diag <prog> ($<[0]) -> $>
And for other operations:
diag <prog> $>
For details, see the print_diag() API description in diagnostics.hxx. See
also GitHub issue #40 for additional background/details.
* Buffering of diagnostics from child processes.
By default, unless running serially or --no-diag-buffer is specified,
diagnostics issued by child processes (compilers, etc) is buffered and
printed all at once after each child exits in order to prevent
interleaving. See also the new --[no-]diag-color options.
* New $path.posix_string() and $path.posix_representation() functions.
These functions are similar to $path.string() and $path.representation()
except that they always return the string/representation of a path in the
POSIX notation, that is, using forward slashes.
* New $regex.filter[_out]_{match,search}(<vals>, <pat>) functions.
The match versions return elements of a list that match (filter) or do not
match (filter_out) the regular expression. The search versions do the same
except for the search instead of match regex semantics.
* New $find(<sequence>, <value>), $find_index(<sequence>, <value>) functions.
The $find() function returns true if the sequence contains the specified
value. The $find_index() function returns the index of the first element
in the sequence that is equal to the specified value or $size(<sequence>)
if none is found. For string sequences, it's possible to request case-
insensitive comparison with a flag, for example:
if ($find ($values, 'foo', icase))
...
* New $integer_sequence(<begin>, <end>[, <step>]) function.
This function returns the list of uint64 integers starting from <begin>
(including) to <end> (excluding) with the specified <step> or 1 if
unspecified. For example:
hdr = foo.hxx bar.hxx baz.hxx
src = foo.cxx bar.cxx baz.cxx
assert ($size($hdr) == $size($src)) "hdr and src expected to be parallel"
for i: $integer_sequence(0, $size($hdr))
{
h = ($hdr[$i])
s = ($src[$i])
...
}
* New $is_a(<name>, <target-type>), $filter[_out](<names>, <target-types>)
functions.
$is_a() returns true if the <name>'s target type is-a <target-type>. Note
that this is a dynamic type check that takes into account target type
inheritance.
$filter[_out]() return names with target types which are-a (filter) or
not are-a (filter_out) one of <target-types>.
In particular, these functions are useful for filtering prerequisite
targets ($<) in ad hoc recipes and rules.
* Support for the hex notation for the uint64 type.
Specifically, now we can do:
x = [uint64] 0x0000ffff
cxx.poptions += "-DOFFSET=$x" # -DOFFSET=65535
cxx.poptions += "-DOFFSET=$string($x, 16)" # -DOFFSET=0xffff
cxx.poptions += "-DOFFSET=$string($x, 16, 8)" # -DOFFSET=0x0000ffff
Note that there is no hex notation support for the int64 (signed) type.
* Support for the `for` and `while` loops in Buildscript recipes and
Testscript.
For example:
for v: $values
...
end
cat values.txt | for -n v
...
end
while (!$regex.match(...))
...
end
See "Command-For" and "Command-While" in the Testscript manual for
details.
* New `find` builtin in Buildscript recipes and Testscript.
For example:
find gen/ -type f -name '*.?xx' | for -n f
...
end
See "find" in the Testscript manual for details.
* Improvements to escape sequence support.
In the double-quoted strings we now only do effective escaping of the
special [$("\] characters, line continuations, plus [)] for symmetry.
There is now support for "escape sequence expansion" in the $\X form where
\X can be any of the C/C++ simple escape sequences (\n, \t, etc) plus \0
(which in C/C++ is an octal escape sequence). For example:
info "foo$\n$\tbar$\n$\tbaz"
Will print:
buildfile:1:1: info: foo
bar
baz
* New include_arch installation location and the corresponding
config.install.include_arch configuration variable.
This location is meant for architecture-specific files, such as
configuration headers. By default it's the same as the standard include
location but can be configured by the user to a different value (for
example, /usr/include/x86_64-linux-gnu/) for platforms that support
multiple architectures from the same installation location. This is how
one would normally use it from a buildfile:
# The generated configuration header may contain target architecture-
# specific information so install it into include_arch/ instead of
# include/.
#
h{*}: install = include/libhello/
h{config}: install = include_arch/libhello/
* Support for installation filtering.
While project authors determine what gets installed at the buildfile
level, the users of the project can now further filter the installation
using the config.install.filter variable. For details, see "Installation
Filtering" in the manual.
* Support for relocatable installations.
A relocatable installation can be moved to a directory other than its
original installation location. To request a relocatable installation, set
the config.install.relocatable variable to true. For details, see
"Relocatable Installation" in the manual.
* Support for installation manifest.
During the install operation, the config.install.manifest variable can be
set to a file path (or `-`) in order to write the information about all
the filesystem entries being installed into the specified file (or
stdout). The format of the installation manifest is "JSON lines". For
details, see the config.install.manifest variable documentation in the
install module.
* Ability to remap paths in source distributions.
The dist target-specific variable can now specify a path besides true or
false. This path is the "imaginary" source location which is used to
derive the corresponding distribution location. This location can be
either a directory path (to remap with the same file name) or a file path
(to remap with a different name). If the path is relative, then it is
treated relative to the target directory. Note that to make things less
error-prone, simple paths without any directory separators are not allowed
(use ./<name> instead).
Note that if multiple targets end up with the same source location, the
behavior is undefined and no diagnostics is issued. Note also that such
remapping has naturally no effect in the bootstrap distribution mode.
* The in.substitution variable has been renamed to in.mode.
The original name is still recognized for backwards compatibility.
* Ability to specify `in` rule substitutions as key-value pairs.
See "in Module" in the manual for details.
* New public/private variables model.
Now unqualified variables are project-private and can be typed, meaning
that a value assigned to a variable with such a name anywhere within the
project will have this type. For example:
[uint64] priority = [null]
[uint64] stack_size = [null]
priority = 1 # Ok.
stack_size = abc # Error.
Besides the type, variable attributes can specify visibility (project by
default) and overridability (false by default). For example:
thread{*}:
{
[uint64, visibility=target] priority = [null]
[uint64, visibility=target] stack_size = [null]
}
thread{foo}: priority = 1 # Ok.
priority = 1 # Error.
* Support for post hoc prerequisites.
Unlike normal and ad hoc prerequisites, a post hoc prerequisite is built
after the target, not before. It may also form a dependency cycle together
with normal/ad hoc prerequisites. In other words, all this form of
dependency guarantees is that a post hoc prerequisite will be built if its
dependent target is built.
A canonical example where this can be useful is a library with a plugin:
the plugin depends on the library while the library would like to make
sure the plugin is built whenever the library is built so that programs
that link the library can be executed without having to specify explicit
dependency on the plugin (at least for the dynamic linking case):
lib{hello}: ...
lib{hello-plugin}: ... lib{hello}
libs{hello}: libs{hello-plugin}: include = posthoc
Note that there is no guarantee that post hoc prerequisites will be built
before the dependents of the target "see" it as built. Rather, it is
guaranteed that post hoc prerequisites will be built before the end of the
overall build (more precisely, before the current operation completes).
As a result, post hoc prerequisites should not be relied upon if the
result (for example, a source code generator) is expected to be used
during build (more precisely, within the same operation).
Note also that the post hoc semantics is not the same as order-only in
GNU make. In fact, it is an even more "relaxed" form of dependency.
Specifically, while order-only prerequisite is guaranteed to be built
before the target, post hoc prerequisite is only guaranteed to be built
before the end of the overall build.
* Support for dumping build system state in the JSON format.
The new --dump-format option can be used to select the desired format.
Its valid values are `buildfile` and `json-v0.1`. For details on the JSON
dump format see "Appendix A - JSON Dump Format" in the manual.
* Change to the --dump option semantics.
This option now recognizes two additional values: `match-pre` and
`match-post` to dump the state of pre/post-operations. The `match` value
now only triggers dumping of the main operation.
* New --dump-scope and --dump-target options to limit --dump output.
* New --load-only option in addition to --match-only.
This option has the effect of loading all the subdirectory buildfiles that
are not explicitly included and is primarily useful in combination with
--dump.
* Quoted/display target names in the JSON structured result are now
consistent with the JSON dump.
Specifically, before we had `target` (display) and `quoted_target` and now
we have `target` (quoted) and `display_target`. Note that this is a
backwards-incompatible change.
* The dist meta-operation no longer invokes the install program.
This results in a substantial speedup, especially on Windows. The use of
install (or another install-like program) can still be forced with
explicit config.dist.cmd=install.
* Clang -Wunqualified-std-cast-call warning was remapped to -Wextra.
Clang 15 introduced the -Wunqualified-std-cast-call warning which warns
about unqualified calls to std::move() and std::forward() (because they
can be "hijacked" via ADL). Surprisingly, this warning is enabled by
default, as opposed to with -Wextra or at least -Wall. It has also proven
to be quite disruptive, causing a large number of warnings in a large
number of packages. So we have "remapped" it to -Wextra for now and in the
future may "relax" it to -Wall and potentially to being enabled by
default. See GitHub issue #259 for background and details.
Version 0.15.0
* Generated C/C++ headers and ad hoc sources are now updated during match.
Specifically, all headers as well as ad hoc headers and sources are now
treated by the cc::link_rule as if they had update=match unless explicit
update=execute is specified (see below on the update operation-specific
variable).
This change should be transparent to most projects. For background and
discussion of rare cases where you may wish to disable this, see:
https://github.com/build2/HOWTO/blob/master/entries/handle-auto-generated-headers.md
* Support for rule hints.
A rule hint is a target attribute, for example:
[rule_hint=cxx] exe{hello}: c{hello}
Rule hints can be used to resolve ambiguity when multiple rules match the
same target as well as to override an unambiguous match.
In cc::link_rule we now support "linking" libraries without any sources or
headers with a hint. This can be useful for creating "metadata libraries"
whose only purpose is to convey metadata (options to use and/or libraries
to link).
* UTF-8 is now the default input/source character set for C/C++ compilation.
Specifically, the cc module now passes the appropriate compiler option
(/utf-8 for MSVC and -finput-charset=UTF-8 for GCC and Clang) unless a
custom value is already specified (with /{source,execution}-charset for
MSVC and -finput-charset for GCC and Clang).
This change may trigger new compilation errors in your source code if
it's not valid UTF-8 (such errors most commonly point into comments).
For various ways to fix this, see:
https://github.com/build2/HOWTO/blob/master/entries/convert-source-files-to-utf8.md
* Project configuration variables are now non-nullable by default.
A project configuration variable with the NULL default value is naturally
assumed nullable, for example:
config [string] config.libhello.fallback_name ?= [null]
Otherwise, to make a project configuration nullable use the `null`
variable attribute, for example:
config [string, null] config.libhello.fallback_name ?= "World"
* New $relative(<path>, <dir-path>) function.
* New $root_directory(<path>) function.
* New $size() function to get the size of string, path, dir_path.
* New $size() function to get the size of a sequence (strings, paths, etc).
* New $sort() function to sort a sequence (strings, paths, etc).
The function has the following signature:
$sort(<sequence> [, <flags>])
The following flag is supported by all the overloads:
dedup - in addition to sorting also remove duplicates
Additionally, the strings overload also support the following flag:
icase - sort ignoring case
Note that on case-insensitive filesystems the paths and dir_paths
overloads' order is case-insensitive.
* New $config.origin() function for querying configuration value origin.
Give a config.* variable name, this function returns one of `undefined`,
`default`, `buildfile`, or `override`.
* Recognition of -pthread as a special -l option in *.libs.
For background, see:
https://github.com/build2/HOWTO/blob/master/entries/link-pthread.md
* The bin.whole (whole archive) value is now saved in generated pkg-config
files.
* Ability to customize header and library search paths in generated
pkg-config files.
Specifically, {cc,c,cxx}.pkgconfig.{include,lib} variables specify header
(-I) and library (-L) search paths to use in the generated pkg-config
files instead of the default install.{include,lib}. Relative paths are
resolved as installation paths. For example:
lib{Qt6Core}: cxx.pkgconfig.include = include/qt6/
* Ability to save user metadata in C/C++ libraries, including in generated
pkg-config files.
For background and details, see:
https://github.com/build2/HOWTO/blob/master/entries/convey-additional-information-with-exe-lib.md
* Support for rule-specific search in immediate import.
We can now nominate a rule to perform the rule-specific search (if
required) using the rule_hint attribute. For example:
import! [metadata, rule_hint=cxx.link] lib = libhello%lib{hello}
* Support for dynamic dependencies in ad hoc recipes.
Specifically, the `depdb` builtin now has the new `dyndep` command that
can be used to extract dynamic dependencies from program output or a
file. For example, from program output:
obje{hello.o}: cxx{hello}
{{
s = $path($<[0])
o = $path($>)
poptions = $cxx.poptions $cc.poptions
coptions = $cc.coptions $cxx.coptions
depdb dyndep $poptions --what=header --default-type=h -- \
$cxx.path $poptions $coptions $cxx.mode -M -MG $s
diag c++ ($<[0])
$cxx.path $poptions $coptions $cxx.mode -o $o -c $s
}}
Or, alternatively, from a file:
t = $(o).t
depdb dyndep $poptions --what=header --default-type=h --file $t -- \
$cxx.path $poptions $coptions $cxx.mode -M -MG $s >$t
The above depdb-dyndep commands will run the C++ compiler with the -M -MG
options to extract the header dependency information, parse the resulting
make dependency declaration (either from stdout or from file) and enter
each header as a prerequisite of the obje{hello.o} target, as if they were
listed explicitly. It will also save this list of headers in the auxiliary
dependency database (hello.o.d file) in order to detect changes to these
headers on subsequent updates. The --what option specifies what to call
the dependencies being extracted in diagnostics. The --default-type option
specifies the default target type to use for a dependency if its file name
cannot be mapped to a target type.
The above depdb-dyndep variant extracts the dependencies ahead of the
compilation proper and will handle auto-generated headers (see the -MG
option for details) provided we pass the header search paths where they
could be generated with the -I options (passed as $poptions in the above
example).
If there can be no auto-generated dependencies or if they can all be
listed explicitly as static prerequisites, then we can use a variant of
the depdb-dyndep command that extracts the dependencies as a by-product of
compilation. In this mode only the --file input is supported. For example
(assuming hxx{config} is auto-generated):
obje{hello.o}: cxx{hello} hxx{config}
{{
s = $path($<[0])
o = $path($>)
t = $(o).t
poptions = $cxx.poptions $cc.poptions
coptions = $cc.coptions $cxx.coptions
depdb dyndep --byproduct --what=header --default-type=h --file $t
diag c++ ($<[0])
$cxx.path $poptions $coptions $cxx.mode -MD -MF $t -o $o -c $s
}}
Other options supported by the depdb-dyndep command:
--format <name>
Dependency format. Currently only the `make` dependency format is
supported and is the default.
--cwd <dir>
Working directory used to complete relative dependency paths. This
option is currently only valid in the --byproduct mode (in the normal
mode relative paths indicate non-existent files).
--adhoc
Treat dynamically discovered prerequisites as ad hoc (so they don't end
up in $<; only in the normal mode).
--drop-cycles
Drop prerequisites that are also targets. Only use this option if you
are sure such cycles are harmless, that is, the output is not affected
by such prerequisites' content.
--update-{include,exclude} <tgt>|<pat>
Prerequisite targets/patterns to include/exclude (from the static
prerequisite set) for update during match (those excluded will be
updated during execute). The order in which these options are specified
is significant with the first target/pattern that matches determining
the result. If only the --update-include options are specified, then
only the explicitly included prerequisites will be updated. Otherwise,
all prerequisites that are not explicitly excluded will be updated. If
none of these options is specified, then all the static prerequisites
are updated during match. Note also that these options do not apply to
ad hoc prerequisites which are always updated during match.
The common use-case for the --update-exclude option is to omit updating
a library which is only needed to extract exported preprocessor options.
Here is a typical pattern:
import libs = libhello%lib{hello}
libue{hello-meta}: $libs
obje{hello.o}: cxx{hello} libue{hello-meta}
{{
s = $path($<[0])
o = $path($>)
lib_poptions = $cxx.lib_poptions(libue{hello-meta}, obje)
depdb hash $lib_poptions
poptions = $cxx.poptions $cc.poptions $lib_poptions
coptions = $cc.coptions $cxx.coptions
depdb dyndep $poptions --what=header --default-type=h \
--update-exclude libue{hello-meta} -- \
$cxx.path $poptions $coptions $cxx.mode -M -MG $s
diag c++ ($<[0])
$cxx.path $poptions $coptions $cxx.mode -o $o -c $s
}}
As another example, sometimes we need to extract the "common interface"
preprocessor options that are independent of the the library type (static
or shared). For example, the Qt moc compiler needs to "see" the C/C++
preprocessor options from imported libraries if they could affect its
input. Here is how we can implement this:
import libs = libhello%lib{hello}
libul{hello-meta}: $libs
cxx{hello-moc}: hxx{hello} libul{hello-meta} $moc
{{
s = $path($<[0])
o = $path($>[0])
t = $(o).t
lib_poptions = $cxx.lib_poptions(libul{hello-meta})
depdb hash $lib_poptions
depdb dyndep --byproduct --drop-cycles --what=header --default-type=h \
--update-exclude libul{hello-meta} --file $t
diag moc ($<[0])
$moc $cc.poptions $cxx.poptions $lib_poptions \
-f $leaf($s) --output-dep-file --dep-file-path $t -o $o $s
}}
Planned future improvements include support for the `lines` (list of
files, one per line) input format in addition to `make` and support for
dynamic targets in addition to prerequisites.
* Support for specifying custom ad hoc pattern rule names.
Besides improving diagnostics, this allows us to use such a name in the
rule hints, for example:
[rule_name=hello.link] exe{~'/(.*)/'}: obje{~'/\1/'}
{{
$cxx.path -o $path($>) $path($<[0])
}}
[rule_hint=hello] exe{hello}: obje{hello}
obje{hello}: c{hello-c}
* Ability to disfigure specific configuration variables.
The new config.config.disfigure variable can be used to specify the list
of variables to ignore when loading config.build (and any files specified
in config.config.load), letting them to take on the default values. For
example:
$ b configure config.config.disfigure=config.hello.fancy
Besides names, variables can also be specified as patterns in the
config.<prefix>.(*|**)[<suffix>] form where `*` matches single
component names (i.e., `foo` but not `foo.bar`), and `**` matches
single and multi-component names. Currently only single wildcard (`*` or
`**`) is supported. Additionally, a pattern in the config.<prefix>(*|**)
form (i.e., without `.` after <prefix>) matches config.<prefix>.(*|**)
plus config.<prefix> itself (but not config.<prefix>foo).
For example, to disfigure all the project configuration variables (while
preserving all the module configuration variables; note quoting to prevent
pattern expansion):
$ b config.config.disfigure="'config.hello**'"
* Ability to omit loading config.build.
If the new config.config.unload variable is set to true, then omit loading
the project's configuration from the config.build file. Note that the
configuration is still loaded from config.config.load if specified. Note
also that similar to config.config.load, only overrides specified on this
project's root scope and global scope are considered.
* Ability to match libul{} targets.
The bin.libul rule picks, matches, and unmatches (if possible) a member
for the purpose of making its metadata (for example, library's poptions,
if it's one of the cc libraries) available.
* Ability to get common interface options via ${c,cxx}.lib_poptions().
Specifically, the output target type may now be omitted for utility
libraries (libul{} and libu[eas]{}). In this case, only "common interface"
options will be returned for lib{} dependencies. This is primarily useful
for obtaining poptions to be passed to tools other than C/C++ compilers
(for example, Qt moc).
* Ability to control -I translation to -isystem or /external:I in
${c,cxx}.lib_poptions().
See the function documentation for details.
* New `update` operation-specific variable.
This variable is similar to the already existing `clean` and `test`
variables but besides the standard `true` and `false` values, it can also
be set to `unmatch` (match but do not update) and `match` (update during
match) and `execute` (update during execute, as is normally; this value is
primarily useful if the rule has the `match` semantics by default).
Note that the unmatch (match but do not update) and match (update during
match) values are only supported by certain rules (and potentially only
for certain prerequisite types).
Additionally:
- All the operation-specific variables are now checked for `false` as an
override for the prerequisite-specific `include` variable. This can now
be used to disable a prerequisite for update, for example:
./: exe{test}: update = false
- Ad hoc Buildscript recipes now support update=unmatch|match.
- The cc::link_rule now supports the `match` value for headers and ad hoc
prerequisites. This can be used to make sure all the library headers are
updated before matching any of its (or dependent's) object files.
* New build.mode global scope variable.
This variable signals the mode the build system may be running in. The two
core modes are `no-external-modules` (bootstrapping of external modules is
disabled, see --no-external-modules for details) and `normal` (normal
execution). Other build system drivers may invent additional modes (for
example, the bpkg `skeleton` mode; see "Package Build System Skeleton" in
the package manager manual for details).
* New cmdline value type for canned command lines.
The Testscript and Buildscript languages now use the special cmdline value
type for canned command lines. Specifically, the re-lexing after expansion
now only happens if the expended value is of the cmdline type. See
"Lexical Structure" in the Testscript manual for details.
* The bash build system module now installs bash modules into
bin/<project>.bash/ instead of bin/<project>/ to avoid clashes.
* New --trace-{match,execute} options.
These options can be used to understand which dependency chain causes
matching or execution of a particular target. See b(1) for details.
* JSON format support for the --structured-result option and the info meta
operation.
See b(1) for details.
* Switch to using libpkg-config instead of libpkfconf for loading pkg-config
files.
Version 0.14.0
* Support for hermetic build configurations.
Hermetic build configurations save environment variables that affect the
project along with other project configuration in the config.build file.
These saved environment variables are then used instead of the current
environment when performing operations on the project, thus making sure
the project "sees" exactly the same environment as during configuration.
The built-in ~host and ~build2 configurations are now hermetic.
Hermetic configuration support is built on top of the lower-level
config.config.environment configuration variable which allows us to save a
custom set of environment variables/values.
As part of this work we now also track changes to the environment in non-
hermetic configurations and automatically rebuild affected targets.
See "Hermetic Build Configurations" in the manual for details.
* Support for ad hoc regex pattern rules.
An ad hoc pattern rule consists of a pattern that mimics a dependency
declaration followed by one or more recipes. For example:
exe{~'/(.*)/'}: cxx{~'/\1/'}
{{
$cxx.path -o $path($>) $path($<[0])
}}
If a pattern matches a dependency declaration of a target, then the recipe
is used to perform the corresponding operation on this target. For
example, the following dependency declaration matches the above pattern
which means the rule's recipe will be used to update this target:
exe{hello}: cxx{hello}
While the following declarations do not match the above pattern:
exe{hello}: c{hello} # Type mismatch.
exe{hello}: cxx{howdy} # Name mismatch.
On the left hand side of `:` in the pattern we can have a single target or
an ad hoc target group. The single target or the first (primary) ad hoc
group member must be a regex pattern (~). The rest of the ad hoc group
members can be patterns or substitutions (^). For example:
<exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'}
{{
$cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
}}
On the right hand side of `:` in the pattern we have prerequisites which
can be patterns, substitutions, or non-patterns. For example:
<exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'} hxx{^'/\1/'} hxx{common}
{{
$cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
}}
Substitutions on the left hand side of `:` and substitutions and non-
patterns on the right hand side are added to the dependency declaration.
For example, given the above rule and dependency declaration, the
effective dependency is going to be:
<exe{hello} file{hello.map}>: cxx{hello} hxx{hello} hxx{common}
Similar to ad hoc recipes, ad hoc rules can be written in Buildscript or
C++.
* Support for regex patterns in target type/pattern-specific variables.
This is in addition to the already supported path patterns. For example:
hxx{*}: x = y # path pattern
hxx{~/.*/}: x = y # regex pattern
* New pre-defined semantics for the config.<project>.develop variable.
This variable allows a project to distinguish between development and
consumption builds. While normally there is no distinction, sometimes a
project may need to provide additional functionality during development.
For example, a source code generator which uses its own generated code in
its implementation may need to provide a bootstrap step from the pre-
generated code. Normally, such a step is only needed during development.
If used, this variable should be explicitly defined by the project with
the bool type and the false default value. For example:
config [bool] config.hello.develop ?= false
See "Project Configuration" in the manual for details.
* Support for warning suppression from external C/C++ libraries.
This is implemented by defining a notion of a project's internal scope and
automatically translating header search path options (-I) exported by
libraries that are outside of the internal scope to appropriate "external
header search path" options (-isystem for GCC/Clang, /external:I for MSVC
16.10 and later). In the future this functionality will be extended to
side-building BMIs for external module interfaces and header units.
Note that this functionality is not without limitations and drawbacks and,
if needed, should be enabled explicitly. See the "Compilation Internal
Scope" section in the manual for details.
* C++20 modules support in GCC 11 using the module mapper.
This support covers all the major C++20 modules features including named
modules, module partitions (both interface and implementation), header
unit importation, and include translation. All of these features are also
supported in libraries, including consumption of installed libraries with
information about modules and importable headers conveyed in pkg-config
files. Module interface-only libraries are also supported.
Note that one area that is not yet well supported (due to module mapper
limitations) is auto-generated headers. Also note that as of version 11,
support for modules in GCC is still experimental and incomplete.
* Support for automatic DLL symbol exporting.
It is now possible to automatically generate a .def file that exports all
symbols from a Windows DLL. See "Automatic DLL Symbol Exporting" in the
manual for details.
* Initial Emscripten compiler support.
- Target: wasm32-emscripten (wasm32-unknown-emscripten).
- Compiler id: clang-emscripten (type clang, variant emscripten, class
gcc).
- Ability to build executables (.js plus .wasm) and static libraries (.a).
Set executable bit on the .js file (so it can be executed with a
suitable binfmt interpreter). Track the additional .worker.js file if
-pthread is specified.
- Default config.bin.lib for wasm32-emscripten is static instead of both.
- Full C++ exception support is enabled by default unless disabled
explicitly by the user with -s DISABLE_EXCEPTION_CATCHING=1|2.
- The bin module registers the wasm{} target type for wasm32-emscripten.
* New string functions: $string.trim(), $string.lcase(), $string.ucase().
* Support for test runners (config.test.runner).
Support for test timeouts (config.test.timeout).
See "test Module" in the manual for details.
* New <version> install directory substitution in addition to <project>.
New config.install.etc variable with the data_root/etc/ default.
See the "install Module" chapter in the manual for details.
* Support for fallback substitution in the in module (in.null variable).
See "in Module" in the manual for details.
* New export pseudo-builtin that allows adding/removing variables to/from
the current scope's commands execution environment.
See the Testscript manual for details.
* New ad hoc recipe depdb preamble.
The Buildscript language now provides a new pseudo-builtin, depdb, that
allows tracking of custom auxiliary dependency information. Invocations of
this builtin should come before any recipe commands and are collectively
called the depdb preamble. Non-pure functions can now only be called as
part of this preamble. For example:
file{output}: file{input} $foo
{{
diag foo $>
depdb env FOO # foo uses the FOO environment variable
$foo $path($<[0]) >$path($>)
}}