Age | Commit message (Collapse) | Author | Files | Lines |
|
GCC 10+ and Clang 4+ support controlling the number of LTO threads/jobs used
during linking. Use the build2 scheduler to allocate up to the number of
hardware threads to the GCC or Clang linker processes when -flto=auto or
-flto=thin is specified, respectively. Otherwise, GCC or Clang will attempt to
spawn the number of hardware threads detected for each linker process, which
could result in up to n^2 linker threads on a CPU with n hardware threads.
|
|
This allows one to use all of the properties of iterators to manipulate the
found option.
|
|
|
|
|
|
|
|
|
|
|
|
Testing shows quite a lot of "full" conditions on low core count (e.g., 2)
CPUs (such as Intel U-series).
|
|
|
|
Also make sure diff refers program stdout as 'stdout' rather than '-' in the
test rule diagnostics.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This option implements the 'c' part in /EHsc and is not a mere optimization;
see Clang bug #45021 for details.
|
|
|
|
|
|
It turns out that when propagating {c,cxx}.config in tests we don't want to
propagate any options (such as *.std) that have been folded into our project's
mode.
|
|
|
|
|
|
|
|
|
|
This is for consistency with version constraints in manifest.
|
|
|
|
|
|
Specifically, they are reserved for future support of arithmetic evaluation
contexts and evaluation pipelines, respectively.
|
|
|
|
This way they are accessible in ad hoc recipes.
|
|
|
|
|
|
|
|
This is analogous to what has been done to test and install a couple of
commits before.
|
|
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.
|
|
|
|
|
|
|
|
While these can be useful on their own, this also makes the test and install
operations available in simple projects, which is handy for "glue" projects
that "pull" (using ad hoc import) a bunch of other projects.
|
|
|
|
|
|
|
|
|
|
Failed that, they may pull headers via an ad hoc group.
|
|
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.
|