| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
See the "Compilation Database" section in the "cc Module" chapter of
the manual for details.
|
|
|
|
|
|
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)
|
|
|
|
|
|
Note that Clang 17 is not longer supported with regards to standard
library modules.
|
|
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
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As a heuristics, prefer shorter but exact partition name matches to
longer but partial.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that modules support now require Clang 16 or later.
|
|
Also make fsdir_rule::perform_{update,clean}_direct() harder to misuse.
|
|
Module interface and implementation partitions are like module interfaces so
it's not surprising they require similar compilation steps. See GH PR #328 for
background.
|
|
|
|
|
|
|
|
See llvm-project issue 63284 for details.
|
|
|
|
|
|
|
|
Specifically, the c module now provides the c.as-cpp submodules which can be
loaded in order to register the S{} target type and enable Assembler with C
Preprocessor compilation in the c compile rule. For details, refer to
"Assembler with C Preprocessor Compilation" in the manual.
|
|
In particular, we were adding -L/usr/local/lib which means it is considered
before built-in directories (/usr/lib, etc) but in our own library search
code we were considering it after (because we were storing it at the end of
sys_lib_dirs).
Now in both sys_{hdr,lib}_dirs we store /usr/local/{include,lib} after mode
and before built-in directories. Note that as part of this fix we now pass
-isystem /usr/local/include instead of -idirafter (which is consistent with
the -L behavior and also the customarily expected semantics).
|
|
This is used by bpkg to detect forwarded configurations without incurring
the full context creation overhead.
|
|
|
|
|
|
|
|
|
|
|
