| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
See the "Compilation Database" section in the "cc Module" chapter of
the manual for details.
|
|
Specifically, both the C/C++ compiler and link rules now recognize the
cc.serialize boolean variable which instructs them to compiler/link
serially with regards to any other recipe.
This is primarily useful when compiling large translation units or linking
large binaries that require so much memory that doing that in parallel with
other compilation/linking jobs is likely to summon the OOM killer. For
example:
obj{memory-hog}: cc.serialize = true
|
|
Specifically, the new config.cc.pkgconfig.sysroot variable provides roughly
equivalent functionality to PKG_CONFIG_SYSROOT_DIR in pkg-config. For details
and limitations, see "Rewriting Installed Libraries System Root (sysroot)"
in the manual for details.
|
|
|
|
|
|
We still always use the public var_pool from context but where required,
all access now goes through scope::var_pool().
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
The bin.def module is automatically loaded by the c and cxx modules for
the *-win32-msvc target architecture. This allows automatically exporting
all symbols for all Windows targets using the following setup (showing
for cxx in this example):
lib{foo}: libul{foo}: {hxx cxx}{**} ...
lib{foo}: def{foo}: include = ($cxx.target.system == 'win32-msvc')
def{foo}: libul{foo}
if ($cxx.target.system == 'mingw32')
cxx.loptions += -Wl,--export-all-symbols
That is, we use the .def file generation for MSVC and the built-in support
(--export-all-symbols) for MinGW.
But it is also possible to use the .def file generation for MinGW. In this
case we need to explicitly load the bin.def module (which should be done
after loading c or cxx) and using the following setup:
using bin.def # In root.build.
lib{foo}: libul{foo}: {hxx cxx}{**} ...
lib{foo}: def{foo}: include = ($cxx.target.class == 'windows')
def{foo}: libul{foo}
|
|
|
|
See the config.cxx.translate_include variable documentation in cxx/init.cxx
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.
|
|
|
|
|
|
|
|
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)"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Such options are (normally) not overridden by buildfiles and are passed
last (after cc.coptions and {c,cxx}.coptions) in the resulting command
lines. They are also cross-hinted between config.c and config.cxx. For
example:
$ b config.cxx="g++ -m64"
|
|
|
