aboutsummaryrefslogtreecommitdiff
path: root/NEWS
diff options
context:
space:
mode:
Diffstat (limited to 'NEWS')
-rw-r--r--NEWS659
1 files changed, 329 insertions, 330 deletions
diff --git a/NEWS b/NEWS
index 5f8a36a..4602fd3 100644
--- a/NEWS
+++ b/NEWS
@@ -1,518 +1,517 @@
Version 0.11.0
- * Initial work on header unit importation and include translation support.
+ * Initial work on header unit importation and include translation support.
- In particular, for GCC, the (experimental) module mapper approach is now
- used to handle header unit importation, include translation, and headers
- dependency extraction, all with support for auto-generated headers.
+ In particular, for GCC, the (experimental) module mapper approach is now
+ used to handle header unit importation, include translation, and headers
+ dependency extraction, all with support for auto-generated headers.
- * Generalized target/prerequisite variable blocks.
+ * Generalized target/prerequisite variable blocks.
- Target/prerequisite-specific variable blocks can now be present even if
- there are prerequisites. For example, now instead of:
+ Target/prerequisite-specific variable blocks can now be present even if
+ there are prerequisites. For example, now instead of:
- exe{foo}: cxx{foo}
- exe{foo}: cc.loptions += -rdynamic
+ exe{foo}: cxx{foo}
+ exe{foo}: cc.loptions += -rdynamic
- Or:
+ Or:
- exe{foo}: cxx{foo}
- exe{foo}:
- {
- cc.loptions += -rdynamic
- cc.libs += -ldl
- }
+ exe{foo}: cxx{foo}
+ exe{foo}:
+ {
+ cc.loptions += -rdynamic
+ cc.libs += -ldl
+ }
- We can write:
+ We can write:
- exe{foo}: cxx{foo}
- {
- cc.loptions += -rdynamic
- cc.libs += -ldl
- }
+ exe{foo}: cxx{foo}
+ {
+ cc.loptions += -rdynamic
+ cc.libs += -ldl
+ }
- This also works with dependency chains in which case the block applies
- to the set of prerequisites (note: not targets) before the last ':'. For
- example:
+ This also works with dependency chains in which case the block applies to
+ the set of prerequisites (note: not targets) before the last ':'. For
+ example:
- ./: exe{foo}: libue{foo}: cxx{foo}
- {
- bin.whole = false # Applies to the libue{foo} prerequisite.
- }
+ ./: exe{foo}: libue{foo}: cxx{foo}
+ {
+ bin.whole = false # Applies to the libue{foo} prerequisite.
+ }
- * Support for ad hoc target groups.
+ * Support for ad hoc target groups.
- In certain cases we may need to instruct the underlying tool (compiler,
- linker, etc) to produce additional outputs. For example, we may want to
- request the compiler to produce an assembler listing or the linker to
- produce a map file. While we could already pass the required options, the
- resulting files will not be part of the build state. Specifically, they
- will not be cleaned up and we cannot use them as prerequisites of other
- targets.
+ In certain cases we may need to instruct the underlying tool (compiler,
+ linker, etc) to produce additional outputs. For example, we may want to
+ request the compiler to produce an assembler listing or the linker to
+ produce a map file. While we could already pass the required options, the
+ resulting files will not be part of the build state. Specifically, they
+ will not be cleaned up and we cannot use them as prerequisites of other
+ targets.
- Ad hoc target groups allow us to specify that updating a target produces
- additional outputs, called ad hoc group members. For example:
+ Ad hoc target groups allow us to specify that updating a target produces
+ additional outputs, called ad hoc group members. For example:
- <exe{hello} file{hello.map}>: cxx{hello}
- {
- cc.loptions += "-Wl,-Map=$out_base/hello.map"
- }
+ <exe{hello} file{hello.map}>: cxx{hello}
+ {
+ cc.loptions += "-Wl,-Map=$out_base/hello.map"
+ }
- <obje{hello} file{hello.lst}>:
- {
- cc.coptions += "-Wa,-amhls=$out_base/hello.lst"
- }
+ <obje{hello} file{hello.lst}>:
+ {
+ cc.coptions += "-Wa,-amhls=$out_base/hello.lst"
+ }
- Note also that all things ad hoc (prerequisites, targets, rules) are still
- under active development so further improvements (such as not having to
- repeat names twice) are likely.
+ Note also that all things ad hoc (prerequisites, targets, rules) are still
+ under active development so further improvements (such as not having to
+ repeat names twice) are likely.
- * New config.{c,cxx}.std configuration variables that, if present, override
- {c,cxx}.std specified at the project level.
+ * New config.{c,cxx}.std configuration variables that, if present, override
+ {c,cxx}.std specified at the project level.
- In particular, this allows forcing a specific standard for all the projects
- in a build configuration, for example:
+ In particular, this allows forcing a specific standard for all the
+ projects in a build configuration, for example:
- $ b create: exp-conf/,cc config.cxx=g++ config.cxx.std=experimental
+ $ b create: exp-conf/,cc config.cxx=g++ config.cxx.std=experimental
- * New --dry-run|-n option instructs build rules to print commands without
- actually executing them.
+ * New --dry-run|-n option instructs build rules to print commands without
+ actually executing them.
- Note that commands that are required to create an accurate build state will
- still be executed and the extracted auxiliary dependency information saved.
- In other words, this is not the "don't touch the filesystem" mode but
- rather "do minimum amount of work to show what needs to be done". In
- particular, this mode is useful to quickly generate the compilation
- database, for example:
+ Note that commands that are required to create an accurate build state
+ will still be executed and the extracted auxiliary dependency information
+ saved. In other words, this is not the "don't touch the filesystem" mode
+ but rather "do minimum amount of work to show what needs to be done". In
+ particular, this mode is useful to quickly generate the compilation
+ database, for example:
- $ b -vn clean update |& compiledb
+ $ b -vn clean update |& compiledb
- * Ability to disable automatic rpath, support for custom rpath-link.
+ * Ability to disable automatic rpath, support for custom rpath-link.
- Specifically, the new config.bin.rpath.auto variable can be used to disable
- automatic addition of prerequisite library rpaths, for example:
+ Specifically, the new config.bin.rpath.auto variable can be used to
+ disable automatic addition of prerequisite library rpaths, for example:
- $ b config.bin.rpath.auto=false
+ $ b config.bin.rpath.auto=false
- Note that in this case rpath-link is still added where normally required
- and for target platforms that support it (Linux and *BSD).
+ Note that in this case rpath-link is still added where normally required
+ and for target platforms that support it (Linux and *BSD).
- The new config.bin.rpath_link and config.bin.rpath_link.auto have the same
- semantics as config.bin.rpath* but for rpath-link.
+ The new config.bin.rpath_link and config.bin.rpath_link.auto have the same
+ semantics as config.bin.rpath* but for rpath-link.
- * Enable MSVC strict mode (/permissive-) for 'experimental' standard starting
- from version 15.5.
+ * Enable MSVC strict mode (/permissive-) for 'experimental' standard
+ starting from version 15.5.
Version 0.10.0
- * Support for an alternative build file/directory naming scheme.
+ * Support for an alternative build file/directory naming scheme.
- Now the build/*.build, buildfile, and .buildignore filesystem entries in
- a project can alternatively (but consistently) be called build2/*.build2,
- build2file, and .build2ignore. See a note at the beginning of the Project
- Structure section in the manual for details (motivation, restrictions,
- etc).
+ Now the build/*.build, buildfile, and .buildignore filesystem entries in a
+ project can alternatively (but consistently) be called build2/*.build2,
+ build2file, and .build2ignore. See a note at the beginning of the Project
+ Structure section in the manual for details (motivation, restrictions,
+ etc).
- * Support for multiple variable overrides.
+ * Support for multiple variable overrides.
- Now we can do:
+ Now we can do:
- $ b config.cxx.coptions=-O3 config.cxx.coptions=-O0
+ $ b config.cxx.coptions=-O3 config.cxx.coptions=-O0
- Or even:
+ Or even:
- $ b config.cxx.coptions=-O3 config.cxx.coptions+=-g
+ $ b config.cxx.coptions=-O3 config.cxx.coptions+=-g
- * Support for MSVC 16 (2019).
+ * Support for MSVC 16 (2019).
- * Support for automatic switching to option files (AKA response files) on
- Windows if the linker command line is too long.
+ * Support for automatic switching to option files (AKA response files) on
+ Windows if the linker command line is too long.
- This covers both MSVC link.exe/lib.exe and MinGW gcc.exe/ar.exe.
+ This covers both MSVC link.exe/lib.exe and MinGW gcc.exe/ar.exe.
Version 0.9.0
- * New "Diagnostics and Debugging" section in the manual on debugging build
- issues.
+ * New "Diagnostics and Debugging" section in the manual on debugging build
+ issues.
- * Support for dependency chains.
+ * Support for dependency chains.
- Now instead of:
+ Now instead of:
- ./: exe{foo}
- exe{foo}: cxx{*}
+ ./: exe{foo}
+ exe{foo}: cxx{*}
- We can write:
+ We can write:
- ./: exe{foo}: cxx{*}
+ ./: exe{foo}: cxx{*}
- Or even:
+ Or even:
- ./: exe{foo}: libue{foo}: cxx{*}
+ ./: exe{foo}: libue{foo}: cxx{*}
- This can be combined with prerequisite-specific variables (which naturally
- only apply to the last set of prerequisites in the chain):
+ This can be combined with prerequisite-specific variables (which naturally
+ only apply to the last set of prerequisites in the chain):
- ./: exe{foo}: libue{foo}: bin.whole = false
+ ./: exe{foo}: libue{foo}: bin.whole = false
- * Support for target and prerequisite specific variable blocks.
+ * Support for target and prerequisite specific variable blocks.
- For example, now instead of:
+ For example, now instead of:
- lib{foo}: cxx.loptions += -static
- lib{foo}: cxx.libs += -lpthread
+ lib{foo}: cxx.loptions += -static
+ lib{foo}: cxx.libs += -lpthread
- We can write:
+ We can write:
- lib{foo}:
- {
- cxx.loptions += -static
- cxx.libs += -lpthread
- }
+ lib{foo}:
+ {
+ cxx.loptions += -static
+ cxx.libs += -lpthread
+ }
- The same works for prerequisites as well as target type/patterns. For
- example:
+ The same works for prerequisites as well as target type/patterns. For
+ example:
- exe{*.test}:
- {
- test = true
- install = false
- }
+ exe{*.test}:
+ {
+ test = true
+ install = false
+ }
- * Fallback to loading outer buildfile if there isn't one in the target's
- directory (src_base).
+ * Fallback to loading outer buildfile if there isn't one in the target's
+ directory (src_base).
- This covers the case where the target is defined in the outer buildfile
- which is common with non-intrusive project conversions where everything is
- built from a single root buildfile.
+ This covers the case where the target is defined in the outer buildfile
+ which is common with non-intrusive project conversions where everything is
+ built from a single root buildfile.
- * Command line variable override scope syntax is now consistent with
- buildfile syntax.
+ * Command line variable override scope syntax is now consistent with
+ buildfile syntax.
- Before:
+ Before:
- $ b dir/:foo=bar ...
+ $ b dir/:foo=bar ...
- After:
+ After:
- $ b dir/foo=bar
+ $ b dir/foo=bar
- Alternatively (the buildfile syntax):
+ Alternatively (the buildfile syntax):
- $ b 'dir/ foo=bar'
+ $ b 'dir/ foo=bar'
- Note that the (rarely used) scope visibility modifier now leads to a double
- slash:
+ Note that the (rarely used) scope visibility modifier now leads to a
+ double slash:
- $ b dir//foo=bar
+ $ b dir//foo=bar
- * Support for relative to base scope command line variable overrides.
+ * Support for relative to base scope command line variable overrides.
- Currently, if we do:
+ Currently, if we do:
- $ b dir/ ./foo=bar
+ $ b dir/ ./foo=bar
- The scope the foo=bar is set on is relative to CWD, not dir/. While this
- may seem wrong at first, this is the least surprising behavior when we take
- into account that there can be multiple dir/'s.
+ The scope the foo=bar is set on is relative to CWD, not dir/. While this
+ may seem wrong at first, this is the least surprising behavior when we
+ take into account that there can be multiple dir/'s.
- Sometimes, however, we do want the override directory to be treated
- relative to (every) target's base scope that we are building. To support
- this we are extending the '.' and '..' special directory names (which are
- still resolved relative to CWD) with '...', which means "relative to the
- base scope of every target in the buildspec". For example:
+ Sometimes, however, we do want the override directory to be treated
+ relative to (every) target's base scope that we are building. To support
+ this we are extending the '.' and '..' special directory names (which are
+ still resolved relative to CWD) with '...', which means "relative to the
+ base scope of every target in the buildspec". For example:
- $ b dir/ .../foo=bar
+ $ b dir/ .../foo=bar
- Is equivalent to:
+ Is equivalent to:
- $ b dir/ dir/foo=bar
+ $ b dir/ dir/foo=bar
- And:
+ And:
- $ b liba/ libb/ .../tests/foo=bar
+ $ b liba/ libb/ .../tests/foo=bar
- Is equivalent to:
+ Is equivalent to:
- $ b liba/ libb/ liba/tests/foo=bar libb/tests/foo=bar
+ $ b liba/ libb/ liba/tests/foo=bar libb/tests/foo=bar
- * New config.{c,cxx}.{id,version,target} configuration variables.
+ * New config.{c,cxx}.{id,version,target} configuration variables.
- These variables allow overriding guessed compiler id/version/target, for
- example, in case of mis-guesses or when working with compilers that don't
- report their base (e.g., GCC, Clang) with -v/--version (common in the
- embedded space).
+ These variables allow overriding guessed compiler id/version/target, for
+ example, in case of mis-guesses or when working with compilers that don't
+ report their base (e.g., GCC, Clang) with -v/--version (common in the
+ embedded space).
- * New --[no-]mtime-check options to control backwards modification time
- checks at runtime.
+ * New --[no-]mtime-check options to control backwards modification time
+ checks at runtime.
- By default the checks are enabled only for the staged toolchain.
+ By default the checks are enabled only for the staged toolchain.
- * New --dump <phase> option, remove state dumping from verbosity level 6.
+ * New --dump <phase> option, remove state dumping from verbosity level 6.
- * The info meta-operation now prints the list of operations and meta-
- operations supported by the project.
+ * The info meta-operation now prints the list of operations and meta-
+ operations supported by the project.
- * New sleep Testscript builtin.
+ * New sleep Testscript builtin.
Version 0.8.0
- * BREAKING: rename the .test extension (Testscript file) to .testscript and
- the test{} target type to testscript{}.
+ * BREAKING: rename the .test extension (Testscript file) to .testscript and
+ the test{} target type to testscript{}.
- * Introduction chapter in the build system manual.
+ * Introduction chapter in the build system manual.
- The introduction covers every aspect of the build infrastructure, including
- the underlying concepts, for the canonical executable and library projects
- as produced by bdep-new(1).
+ The introduction covers every aspect of the build infrastructure,
+ including the underlying concepts, for the canonical executable and
+ library projects as produced by bdep-new(1).
- * New 'in' build system module.
+ * New 'in' build system module.
- Given test.in containing something along these lines:
+ Given test.in containing something along these lines:
- foo = $foo$
+ foo = $foo$
- Now we can do:
+ Now we can do:
- using in
+ using in
- file{test}: in{test.in}
- file{test}: foo = FOO
+ file{test}: in{test.in}
+ file{test}: foo = FOO
- The alternative variable substitution symbol can be specified with the
- in.symbol variable and lax (instead of the default strict) mode with
- in.substitution. For example:
+ The alternative variable substitution symbol can be specified with the
+ in.symbol variable and lax (instead of the default strict) mode with
+ in.substitution. For example:
- file{test}: in.symbol = '@'
- file{test}: in.substitution = lax
+ file{test}: in.symbol = '@'
+ file{test}: in.substitution = lax
- * New 'bash' build system module that provides modularization support for bash
- scripts. See the build system manual for all the details.
+ * New 'bash' build system module that provides modularization support for
+ bash scripts. See the build system manual for all the details.
- * Support for 'binless' (binary-less aka header-only) libraries.
+ * Support for 'binless' (binary-less aka header-only) libraries.
- A header-only library (or, in the future, a module interface-only library)
- is not a different kind of library compared to static/shared libraries but
- is rather a binary-less, or binless for short, static or shared library.
- Whether a library is binless is determined dynamically and automatically
- based on the absence of source file prerequisites. See the build system
- manual for details.
+ A header-only library (or, in the future, a module interface-only library)
+ is not a different kind of library compared to static/shared libraries but
+ is rather a binary-less, or binless for short, static or shared library.
+ Whether a library is binless is determined dynamically and automatically
+ based on the absence of source file prerequisites. See the build system
+ manual for details.
- * Use thin archives for utility libraries if available.
+ * Use thin archives for utility libraries if available.
- Thin archives are supported by GNU ar since binutils 2.19.1 and LLVM ar
- since LLVM 3.8.0.
+ Thin archives are supported by GNU ar since binutils 2.19.1 and LLVM ar
+ since LLVM 3.8.0.
- * Support for archive checksum generation during distribution:
+ * Support for archive checksum generation during distribution:
- Now we can do:
+ Now we can do:
- $ b dist: ... \
- config.dist.archives='tar.gz zip' \
- config.dist.checksums='sha1 sha256'
+ $ b dist: ... \
+ config.dist.archives='tar.gz zip' \
+ config.dist.checksums='sha1 sha256'
- And end up with .tar.gz.sha1, .tar.gz.sha256, .zip.sha1, and .zip.sha256
- checksum files in addition to archives.
+ And end up with .tar.gz.sha1, .tar.gz.sha256, .zip.sha1, and .zip.sha256
+ checksum files in addition to archives.
- * Support for excluded and ad hoc prerequisites:
+ * Support for excluded and ad hoc prerequisites:
- The inclusion/exclusion is controlled via the 'include' prerequisite-
- specific variable. Valid values are:
+ The inclusion/exclusion is controlled via the 'include' prerequisite-
+ specific variable. Valid values are:
- false - exclude
- true - include
- adhoc - include but treat as an ad hoc input
+ false - exclude
+ true - include
+ adhoc - include but treat as an ad hoc input
- For example:
+ For example:
- lib{foo}: cxx{win32-utility}: include = ($cxx.targe.class == 'windows')
- exe{bar}: libs{plugin}: include = adhoc
+ lib{foo}: cxx{win32-utility}: include = ($cxx.targe.class == 'windows')
+ exe{bar}: libs{plugin}: include = adhoc
- * C++ Modules support:
+ * C++ Modules support:
- - handle the leading 'module;' marker (p0713)
- - switch to new GCC module interface (-fmodule-mapper)
- - force reprocessing for module interface units if compiling with MSVC
+ - handle the leading 'module;' marker (p0713)
+ - switch to new GCC module interface (-fmodule-mapper)
+ - force reprocessing for module interface units if compiling with MSVC
- * Testscript:
+ * Testscript:
- - new mv builtin
- - new --after <ref-file> option in touch builtin
+ - new mv builtin
+ - new --after <ref-file> option in touch builtin
- * New $process.run() and $process.run_regex() functions:
+ * New $process.run() and $process.run_regex() functions:
- $process.run(<prog>[ <args>...])
+ $process.run(<prog>[ <args>...])
- Return trimmed stdout.
+ Return trimmed stdout.
- $process.run_regex(<prog>[ <args>...], <pat> [, <fmt>])
+ $process.run_regex(<prog>[ <args>...], <pat> [, <fmt>])
- Return stdout lines matched and optionally processed with regex.
+ Return stdout lines matched and optionally processed with regex.
- Each line of stdout (including the customary trailing blank) is matched (as
- a whole) against <pat> and, if successful, returned, optionally processed
- with <fmt>, as an element of a list.
+ Each line of stdout (including the customary trailing blank) is matched
+ (as a whole) against <pat> and, if successful, returned, optionally
+ processed with <fmt>, as an element of a list.
- * Support for name patterns without wildcard characters.
+ * Support for name patterns without wildcard characters.
- In particular, this allows the "if-exists" specification of prerequisites,
- for example:
+ In particular, this allows the "if-exists" specification of prerequisites,
+ for example:
- for t: $tests
- exe{$t}: cxx{$t} test{+$t}
+ for t: $tests
+ exe{$t}: cxx{$t} test{+$t}
- * Functions for decomposing name as target/prerequisite name:
+ * Functions for decomposing name as target/prerequisite name:
- $name.name()
- $name.extension()
- $name.directory()
- $name.target_type()
- $name.project()
+ $name.name()
+ $name.extension()
+ $name.directory()
+ $name.target_type()
+ $name.project()
- * Add support for default extension specification, trailing dot escaping.
+ * Add support for default extension specification, trailing dot escaping.
- For example:
+ For example:
- cxx{*}: extension = cxx
+ cxx{*}: extension = cxx
- cxx{foo} # foo.cxx
- cxx{foo.test} # foo.test (probably what we want...)
- cxx{foo.test...} # foo.test.cxx (... is this)
- cxx{foo..} # foo.
- cxx{foo....} # foo..
- cxx{foo.....} # error (must come in escape pairs)
+ cxx{foo} # foo.cxx
+ cxx{foo.test} # foo.test (probably what we want...)
+ cxx{foo.test...} # foo.test.cxx (... is this)
+ cxx{foo..} # foo.
+ cxx{foo....} # foo..
+ cxx{foo.....} # error (must come in escape pairs)
- * Use (native) C and C++ compilers we were built with as defaults for
- config.c and config.cxx, respectively.
+ * Use (native) C and C++ compilers we were built with as defaults for
+ config.c and config.cxx, respectively.
- * Implement missing pieces in utility libraries support. In particular, we
- can now build static libraries out of utility libraries.
+ * Implement missing pieces in utility libraries support. In particular, we
+ can now build static libraries out of utility libraries.
- * Built-in support for Windows module definition files (.def/def{}).
+ * Built-in support for Windows module definition files (.def/def{}).
- * Project names are now sanitized when forming the config.import.<proj>
- variables. Specifically, '-', '+', and '.' are replaced with '_' to form a
- "canonical" variable name.
+ * Project names are now sanitized when forming the config.import.<proj>
+ variables. Specifically, '-', '+', and '.' are replaced with '_' to form a
+ "canonical" variable name.
Version 0.7.0
- * Initial support for Clang targeting MSVC runtime (native Clang interface,
- not the clang-cl wrapper).
-
- * C++ Modules TS introduction, build system support, and design guidelines
- documentation.
+ * Initial support for Clang targeting MSVC runtime (native Clang interface,
+ not the clang-cl wrapper).
- * New {c,cxx}.guess modules.
+ * C++ Modules TS introduction, build system support, and design guidelines
+ documentation.
- These can be loaded before {c,cxx} to guess the compiler. Based on this
- information we can then choose the standard, experimental features, etc.
- For example:
+ * New {c,cxx}.guess modules.
- using cxx.guess
+ These can be loaded before {c,cxx} to guess the compiler. Based on this
+ information we can then choose the standard, experimental features, etc.
+ For example:
- if ($cxx.id == 'clang')
- cxx.features.modules = false
+ using cxx.guess
- cxx.std = experimental
+ if ($cxx.id == 'clang')
+ cxx.features.modules = false
- using cxx
+ cxx.std = experimental
- * New {c,cxx}.class variables.
+ using cxx
- Compiler class describes a set of compilers that follow more or less
- the same command line interface. Compilers that don't belong to any of
- the existing classes are in classes of their own (say, Sun CC would be
- on its own if we were to support it).
+ * New {c,cxx}.class variables.
- Currently defined compiler classes:
+ Compiler class describes a set of compilers that follow more or less the
+ same command line interface. Compilers that don't belong to any of the
+ existing classes are in classes of their own (say, Sun CC would be on its
+ own if we were to support it).
- gcc gcc, clang, clang-apple, icc (on non-Windows)
- msvc msvc, clang-cl, icc (Windows)
+ Currently defined compiler classes:
- * Support for C/C++ runtime/stdlib detection ({c,cxx}.{runtime,stdlib}
- variables; see cc/guess.hxx for possible values).
+ gcc gcc, clang, clang-apple, icc (on non-Windows)
+ msvc msvc, clang-cl, icc (Windows)
+ * Support for C/C++ runtime/stdlib detection ({c,cxx}.{runtime,stdlib}
+ variables; see cc/guess.hxx for possible values).
- * New __build2_preprocess macro.
+ * New __build2_preprocess macro.
- If cc.reprocess is true, the __build2_preprocess is defined during
- dependency extraction. This can be used to work around separate
- preprocessing bugs in the compiler.
+ If cc.reprocess is true, the __build2_preprocess is defined during
+ dependency extraction. This can be used to work around separate
+ preprocessing bugs in the compiler.
- * Support for for-loop. The semantics is similar to the C++11 range-based
- for:
+ * Support for for-loop. The semantics is similar to the C++11 range-based
+ for:
- list = 1 2 3
- for i: $list
- print $i
+ list = 1 2 3
+ for i: $list
+ print $i
- Note that there is no scoping of any kind for the loop variable ('i' in the
- above example). In the future the plan is to also support more general
- while-loop as well as break and continue.
+ Note that there is no scoping of any kind for the loop variable ('i' in
+ the above example). In the future the plan is to also support more general
+ while-loop as well as break and continue.
- * New info meta operation.
+ * New info meta operation.
- This meta operation can be used to print basic information (name, version,
- source/output roots, etc) for one or more projects.
+ This meta operation can be used to print basic information (name, version,
+ source/output roots, etc) for one or more projects.
- * New update-for-{test,install} operation aliases.
+ * New update-for-{test,install} operation aliases.
- * Support for forwarded configurations with target backlinking. See the
- configure meta-operation discussion in b(1) for details.
+ * Support for forwarded configurations with target backlinking. See the
+ configure meta-operation discussion in b(1) for details.
- * Improvements to the in module (in.symbol, in.substitution={strict|lax}).
+ * Improvements to the in module (in.symbol, in.substitution={strict|lax}).
- * New $directory(), $base(), $leaf() and $extension() path functions.
+ * New $directory(), $base(), $leaf() and $extension() path functions.
- * New $regex.split(), $regex.merge() and $regex.apply() functions.
+ * New $regex.split(), $regex.merge() and $regex.apply() functions.
- * Support for (parallel) bootstrapping using GNU make makefile.
+ * Support for (parallel) bootstrapping using GNU make makefile.
- * Support for chroot'ed install (aka DESTDIR):
+ * Support for chroot'ed install (aka DESTDIR):
- b config.install.root=/usr config.install.chroot=/tmp/install
+ b config.install.root=/usr config.install.chroot=/tmp/install
- * Support for prerequisite-specific variables, used for the bin.whole
- variable ("link whole archive").
+ * Support for prerequisite-specific variables, used for the bin.whole
+ variable ("link whole archive").
- * Regularize directory target/scope-specific variable assignment syntax:
+ * Regularize directory target/scope-specific variable assignment syntax:
- $out_root/: foo = bar # target
- $out_root/ foo = bar # scope
- $out_root/
- {
- foo = bar # scope
- }
+ $out_root/: foo = bar # target
+ $out_root/ foo = bar # scope
+ $out_root/
+ {
+ foo = bar # scope
+ }
- * Support for structured result output (--structured-result).
+ * Support for structured result output (--structured-result).
- * Support for build hooks.
+ * Support for build hooks.
- The following buildfiles are loaded (if present) at appropriate times from
- the out_root subdirectories of a project:
+ The following buildfiles are loaded (if present) at appropriate times from
+ the out_root subdirectories of a project:
- build/bootstrap/pre-*.build # before loading bootstrap.build
- build/bootstrap/post-*.build # after loading bootstrap.build
- build/root/pre-*.build # before loading root.build
- build/root/post-*.build # after loading root.build
+ build/bootstrap/pre-*.build # before loading bootstrap.build
+ build/bootstrap/post-*.build # after loading bootstrap.build
+ build/root/pre-*.build # before loading root.build
+ build/root/post-*.build # after loading root.build
- * New run directive.
+ * New run directive.
- Now it is possible to:
+ Now it is possible to:
- run echo 'foo = bar'
- print $foo
+ run echo 'foo = bar'
+ print $foo
- * New dump directive.
+ * New dump directive.
- It can be used to print (to stderr) a human-readable representation of the
- current scope or a list of targets. For example:
+ It can be used to print (to stderr) a human-readable representation of the
+ current scope or a list of targets. For example:
- dump # Dump current scope.
- dump lib{foo} details/exe{bar} # Dump two targets.
+ dump # Dump current scope.
+ dump lib{foo} details/exe{bar} # Dump two targets.
- This is primarily useful for debugging as well as to write build system
- tests.
+ This is primarily useful for debugging as well as to write build system
+ tests.
Version 0.6.0