| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This variable allows a project to distinguish between development and
consumption builds. While normally there is no distinction between these two
modes, 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.
See "Project Configuration" in the manual for details.
|
|
|
|
|
|
|
|
|
|
See the config.cxx.translate_include variable documentation in cxx/init.cxx
for details.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specifically, they are reserved for future support of arithmetic evaluation
contexts and evaluation pipelines, respectively.
|
|
If the target being imported has no project name and is either absolute or is
a relative directory, then this is treated as ad hoc importation. Semantically
it is similar to a normal import but with the location of the project being
imported hard-coded into the buildfile.
This type of import can be used to create a special "glue buildfile" that
"pulls" together several projects, usually for convenience of development. One
typical case that calls for such a glue buildfile is a multi-package project.
To be able to invoke the build system driver directly in the project root, we
can add a glue buildfile that imports and builds all the packages:
import pkgs = */
./: $pkgs
See "Target Importation" in the manual for details.
|
|
An import without a project name or with the same name as the importing
project's is now treated as importation from the same project.
For example, given the libhello project that exports the lib{hello} target, a
buildfile for an executable in the same project instead of doing something
like this:
include ../libhello/
exe{hello}: ../libhello/lib{hello}
Can now do this:
import lib = libhello%lib{hello}
Or:
import lib = lib{hello}
And then:
exe{hello}: $lib
Note that a target in project-local importation must still be exported in
the project's export stub. In other words, project-local importation goes
through the same mechanisms as normal import.
|
|
Before the block used to apply to the set of prerequisites before the last
`:`. This turned out to be counterintuitive and not very useful since
prerequisite-specific variables are a lot less common than target specific.
And it doesn't fit with ad hoc recipes.
The new rule is if the chain ends with `:`, then the block applies to the last
set of prerequisites. Otherwise, it applies to the last set of targets. For
example:
./: exe{test}: cxx{main}
{
test = true # Applies to the exe{test} target.
}
./: exe{test}: libue{test}:
{
bin.whole = false # Applies to the libue{test} prerequisite.
}
This is actually consistent with both non-chain and non-block cases.
Consider:
exe{test}: cxx{main}
{
test = true
}
exe{test}: libue{test}:
{
bin.whole = false
}
exe{test}: libue{test}: bin.whole = false
The only exception we now have in this overall approach of "if the
dependency declaration ends with a colon, then what follows is for a
prerequisite" is for the first semicolon:
exe{test}:
{
test = true
}
exe{test}: test = true
But that's probably intuitive enough since there cannot be a prerequisite
without a target.
|
|
|
|
A private installation subdirectory can be used to hide the implementation
details of a project. This is primarily useful when installing an executable
that depends on a bunch of libraries into a shared location, such as
/usr/local/.
|
|
Its default value is data_root/share/ and it is now used as a common root
for config.install.{data,doc,man} variables.
|
|
This allows separation of legal files (LICENSE, AUTHORS, etc) from other
documentation. For example:
./: ... doc{README} legal{LICENSE}
$ b install ... config.install.legal=/usr/share/licenses/hello/
|
|
This feels like an oversight from transitioning to full names, like
testscript{}, etc.
|
|
|
|
Specifically, now config.<tool> (like config.cli) is handled by the import
machinery (it is like a shorter alias for config.import.<tool>.<tool>.exe
that we already had). And the cli module now uses that instead of custom
logic.
This also adds support for uniform tool metadata extraction that is handled by
the import machinery. As a result, a tool that follows the "build2 way" can be
imported with metadata by the buildfile and/or corresponding module without
any tool-specific code or brittleness associated with parsing --version or
similar outputs. See the cli tool/module for details.
Finally, two new flavors of the import directive are now supported: import!
triggers immediate importation skipping any rule-specific logic while import?
is optional import (analogous to using?). Note that optional import is always
immediate. There is also the import-specific metadata attribute which can be
specified for these two import flavors in order to trigger metadata
importation. For example:
import? [metadata] cli = cli%exe{cli}
if ($cli != [null])
info "cli version $($cli:cli.version)"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also document the new bracket expression ([...]) wildcard support.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
