Age | Commit message (Collapse) | Author | Files | Lines |
|
The new config.export variable specifies the alternative file to write the
configuration to as part of the configure meta-operation. For example:
$ b configure: proj/ config.export=proj-config.build
The config.export value "applies" only to the projects on whose root scope it
is specified or if it is a global override (the latter is a bit iffy but we
allow it, for example, to dump everything to stdout). This means that in order
to save a subproject's configuration we will have to use a scope-specific
override (since the default will apply to the outermost amalgamation). For
example:
$ b configure: subproj/ subproj/config.export=.../subproj-config.build
This could be somewhat unnatural but then it will be the amalgamation whose
configuration we normally want to export.
The new config.import variable specifies additional configuration files to be
loaded after the project's default config.build, if any. For example:
$ b create: cfg/,cc config.import=my-config.build
Similar to config.export, the config.import value "applies" only to the
project on whose root scope it is specified or if it is a global override.
This allows the use of the standard override "positioning" machinery (i.e.,
where the override applies) to decide where the extra configuration files are
loaded. The resulting semantics is quite natural and consistent with command
line variable overrides, for example:
$ b config.import=.../config.build # outermost amalgamation
$ b ./config.import=.../config.build # this project
$ b !config.import=.../config.build # every project
Both config.export and config.import recognize the special `-` file name as an
instruction to write/read to/from stdout/stdin, respectively. For example:
$ b configure: src-prj/ config.export=- | b configure: dst-prj/ config.import=-
|
|
Failed that, we may have long periods of seemingly nothing happening (e.g.,
during implicit bdep sync) while we quietly update the module, which may look
like things have hung up.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All non-const global state is now in class context and we can now have
multiple independent builds going on at the same time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
constructor
|
|
|
|
|
|
|
|
string_table class templates
|
|
|
|
Now we can do:
$ b config.cxx.coptions=-O3 config.cxx.coptions=-O0
Or even:
$ b config.cxx.coptions=-O3 config.cxx.coptions+=-g
|
|
|
|
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).
|
|
|
|
|
|
By default the checks are enabled only for the staged toolchain.
|
|
|
|
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.
|
|
Currently, if we say:
$ 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.
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
Is equivalent to:
$ b dir/ dir/foo=bar
And:
$ b liba/ libb/ .../tests/foo=bar
Is equivalent to:
$ b liba/ libb/ liba/tests/foo=bar libb/tests/foo=bar
|
|
For example:
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 pair)
|
|
|
|
|
|
Given test.in containing something along these lines:
foo = $foo$
Now we can do:
using in
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:
file{test}: in.symbol = '@'
file{test}: in.substitution = lax
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|