| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
These options can be used to understand which dependency chain causes matching
or execution of a particular target.
|
|
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.
|
|
Specifically, {cc,c,cxx}.pkgconfig.{include,lib} variables specify header
(-I) and library (-L) search paths to use in the generated .pc files
instead of the default install.{include,lib}. Relative paths are resolved
as install paths.
|
|
|
|
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 we use the `null`
variable attribute, for example:
config [string, null] config.libhello.fallback_name ?= "World"
|
|
|
|
|
|
Also, expect the first component in the import path to be full project
name even in case it has the .bash extension.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
