| 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.
|
|
|
|
Also disable C++ recipe tests when cross-testing.
|
