| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
overloads
|
|
|
|
In particular, this provides support for using prefixed/suffixed installed
libraries (GH issue #449).
|
|
In particular, this provides support for using prefixed/suffixed installed
libraries (GH issue #449). Note that the current implementation only supports
immediate import but it feels like this limitation can be removed with some
effort in the future.
|
|
(GH issue #448)
|
|
|
|
|
|
|
|
Also improve diagnostics around invalid compiledb format.
|
|
See the "Compilation Database" section in the "cc Module" chapter of
the manual for details.
|
|
|
|
|
|
This, for example, can be used to link for ARM64EC instead of the
default ARM64:
"config.cxx=cl.exe /arm64EC" config.cc.loptions=/MACHINE:ARM64EC
|
|
|
|
|
|
|
|
|
|
In particular, this will allow us to use depdb change tracking to also detect
changes to compilation database entries.
|
|
|
|
It is now possible to specify compile option (*.poptions and *.coptions) on
the exe/lib{} targets (we call them "binary-specific compile options"). Such
options are propagated to obj/bmi{} targets that are synthesized for source
prerequisites of the binary. Note that this propagation does not apply to
obj/bmi{} prerequisites. For example:
exe{foo}: cxx{foo} obj{common}
{
cxx.poptions += -DFOO
}
exe{bar}: cxx{bar} obj{common}
{
cxx.poptions += -DBAR
}
obj{common}: cxx{common}
{
cxx.poptions += -DCOMMON
}
In this example, cxx{foo} will be compiled with -DFOO, cxx{bar} -- with
-DBAR, and cxx{common} -- with -DCOMMON.
Note that if a source prerequisite is shared between several binaries, then
the values of the propagated compile options (or their absence) must match.
For instance, the following variant of the above example would result in an
error since cxx{common} would have contradictory cxx.poptions values:
exe{foo}: cxx{foo common}
{
cxx.poptions += -DFOO
}
exe{bar}: cxx{bar common}
{
cxx.poptions += -DBAR
}
As another example, here is how we can rewrite a typical library buildfile
(which requires different macros to distinguish between shared/static builds)
using this mechanism, in this case, to build two libraries in the same scope:
./: lib{foo}: {hxx cxx}{*-foo}
./: lib{bar}: {hxx cxx}{*-bar}
cxx.poptions =+ "-I$out_root" "-I$src_root"
lib{foo}:
{
cxx.poptions += -DFOO
cxx.export.poptions = "-I$out_root" "-I$src_root"
}
liba{foo}:
{
cxx.poptions += -DLIBFOO_STATIC_BUILD
cxx.export.poptions += -DLIBFOO_STATIC
}
libs{foo}:
{
cxx.poptions += -DLIBFOO_SHARED_BUILD
cxx.export.poptions += -DLIBFOO_SHARED
}
lib{bar}:
{
cxx.poptions += -DBAR
cxx.export.poptions = "-I$out_root" "-I$src_root"
}
liba{bar}:
{
cxx.poptions += -DLIBBAR_STATIC_BUILD
cxx.export.poptions += -DLIBBAR_STATIC
}
libs{bar}:
{
cxx.poptions += -DLIBBAR_SHARED_BUILD
cxx.export.poptions += -DLIBBAR_SHARED
}
The exact semantics of this mechanism is as-if the binary-specific compile
options were set on the synthesized obj/bmi{} targets at the end of the
buildfile.
One nuance to keep in mind is that target type/pattern-specific
assign/append/prepend specified for obj/bmi{} will not be in effect for
options specified on lib/exe{}. For example:
cxx.poptions += -DSCOPE
obj{*}: cxx.poptions += -DTARGET
exe{foo}: cxx.poptions += -DFOO
Here the effective cxx.poptions for exe{foo} prerequisites will be
-DSCOPE -DFOO since exe{foo} does not match the obj{*} pattern. As result,
if using this mechanism, remember to include the binary target types in
obj{} patterns. For example:
{obj exe}{*}: cxx.poptions += -DTARGET
|
|
|
|
#390)
|
|
The split one was just too much of an eye-sore in the logs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For background, see:
https://developercommunity.visualstudio.com/t/Please-clarify-ifwhen-Zc:preprocessor/10537317
|
|
|
|
Note that Clang 17 is not longer supported with regards to standard
library modules.
|
|
Specifically:
- Pass -fansi-escape-codes for Clang on Windows.
- Enable diagnostics color by default if already enabled on the terminal.
Only try to enable it ourselves with explicit --diag-color.
|
|
|
|
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
|
|
Fixes GH issue #362.
|
|
Fixes GH issue #368.
|
|
Fixes GH issue #366.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
With -frewrite-includes Clang has issues with correctly tracking location
information (manifests itself as wrong line numbers in debug info, for
example). The result also appears to reference the .Si file instead of the
original source file for some reason.
While at it also omit trying to scan such files since that can be hazardous
(such files sometimes use `#`-style comments).
|
|
Now the configured mode options are appended to buildfile-specified (which
must be specified before loading the guess module).
In particular, this ability to specify the compiler mode in a buildfile is
useful in embedded development where the project may need to hardcode things
like -target, -nostdinc, etc. For example:
cxx.std = 20
cxx.mode = -target riscv32-unknown-unknown -nostdinc
using cxx
|
|
|
|
|
