| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
We still always use the public var_pool from context but where required,
all access now goes through scope::var_pool().
|
|
|
|
In the end, the extra jumping through the hoops doesn't justify the extra
safety we gain. The only plausible accidental mistake is making libul{} a
dependency of ./ but then we don't prevent the same for libue{}, which also
doesn't make much sense. Though, the consequences of doing this for libul{}
could be more severe, like messed up for-install'ness. Oh, well, I guess
people will just have to pay attention (this could be a good check for the
linter we've been thinking about).
|
|
This rule picks, matches, and unmatches (if possible) a member for the
purpose of making its metadata (for example, library's poptions, if
it's one of the cc libraries) available.
|
|
Instead of overriding this function, derived targets must now set the
dynamic_type variable to their static_type in their constructor body.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Seeing that std::map is becoming a common Buildfile variable type.
|
|
|
|
|
|
|
|
Also suppress generation of the object file in cases where we don't need it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Target: wasm32-emscripten (wasm32-unknown-emscripten).
- Compiler id: clang-emscripten (type clang, variant emscripten, class gcc).
- Ability to build executables (.js plus .wasm) and static libraries (.a). Set
executable bit on the .js file (so it can be executed with a suitable binfmt
interpreter).
- Default config.bin.lib for wasm32-emscripten is static instead of both.
- Full C++ exception support is enable unless disabled explicitly by the user
with -s DISABLE_EXCEPTION_CATCHING=1|2.
- The bin module registers the wasm{} target type for wasm32-emscripten.
|
|
|
|
|
|
|
|
|
|
Given a linker output target type ("exe", "lib[as]", or "libu[eas]") return
the target type of lib{} group member ("liba" or "libs") that will be picked
when linking a lib{} group to this target type.
|
|
|
|
|
|
|
|
We were trying to be clever but GCC 10's IPA-SRA optimization didn't like it.
|
|
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)"
|
|
POSIX
|
|
|
|
|
|
The common .pc file is produced by ignoring any static/shared-specific
poptions and splitting loptions/libs into Libs/Libs.private.
It is "best effort", in a sense that it's not guaranteed to be sufficient in
all cases, but it will probably cover the majority of cases, even on Windows,
thanks to automatic dllimport'ing of functions.
|
|
|
|
|
|
|
