| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
Specifically, the `depdb dyndep` builtin now has the --byproduct option (which
must come first). In this mode only the --file input is supported. For example:
obje{hello.o}: cxx{hello}
{{
o = $path($>)
t = $(o).t
depdb dyndep --byproduct --what=header --default-type=h --file $t
diag c++ ($<[0])
$cxx.path $cxx.poptions $cc.poptions $cc.coptions $cxx.coptions $cxx.mode -o $o -MD -MF $t -c $path($<[0])
}}
Naturally, this mode does not support dynamic auto-generated prerequisites.
If present, such prerequisites must be specified statically in the buildfile.
Note also that the --default-prereq-type option has been rename to
--default-type.
|
|
|
|
|
|
|
|
An ad hoc recipe with dynamic dependency extraction (depdb-dyndep) executes
its depdb preamble during match (but after matching all the prerequisites).
|
|
Specifically, add the new `depdb dyndep` builtin that can be used to extract
dynamic dependencies from a program run or a file. For example:
obje{hello.o}: cxx{hello}
{{
s = $path($<[0])
depdb dyndep $cxx.poptions $cc.poptions --what=header --default-prereq-type=h -- $cxx.path $cxx.poptions $cc.poptions $cxx.mode -M -MG $s
diag c++ ($<[0])
o = $path($>)
$cxx.path $cxx.poptions $cc.poptions $cc.coptions $cxx.coptions $cxx.mode -o $o -c $s
}}
Currently only the `make` dependency format is supported.
|
|
|
|
|
|
|
|
|
|
|
|
Fixes GitHub issue #169.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is also now possible to adjust this behavior with global
config.install.scope override. Valid values for this variable
are:
project -- only from project
strong -- from strong amalgamation
weak -- from weak amalgamation
global -- from all projects (default)
|
|
|
|
This function deduplicates interface library dependencies by removing
libraries that are also interface dependencies of the specified
libraries. This can result in significantly better build performance for
heavily interface-interdependent library families (for example, like Boost).
Typical usage:
import intf_libs = ...
import intf_libs += ...
...
import intf_libs += ...
intf_libs = $cxx.deduplicate_export_libs($intf_libs)
|
|
|
|
|
|
|
|
It turns out this is a lot faster on deeply-dependent libraries like Boost
while not having any noticeable differences for "sane" projects.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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}
|
|
|
|
An ad hoc pattern rule consists of a pattern that mimics a dependency
declaration followed by one or more recipes. For example:
exe{~'/(.*)/'}: cxx{~'/\1/'}
{{
$cxx.path -o $path($>) $path($<[0])
}}
If a pattern matches a dependency declaration of a target, then the recipe is
used to perform the corresponding operation on this target. For example, the
following dependency declaration matches the above pattern which means the
rule's recipe will be used to update this target:
exe{hello}: cxx{hello}
While the following declarations do not match the above pattern:
exe{hello}: c{hello} # Type mismatch.
exe{hello}: cxx{howdy} # Name mismatch.
On the left hand side of `:` in the pattern we can have a single target or an
ad hoc target group. The single target or the first (primary) ad hoc group
member must be a regex pattern (~). The rest of the ad hoc group members can
be patterns or substitutions (^). For example:
<exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'}
{{
$cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
}}
On the left hand side of `:` in the pattern we have prerequisites which can
be patterns, substitutions, or non-patterns. For example:
<exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'} hxx{^'/\1/'} hxx{common}
{{
$cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
}}
Substitutions on the left hand side of `:` and substitutions and non-patterns
on the right hand side are added to the dependency declaration. For example,
given the above rule and dependency declaration, the effective dependency is
going to be:
<exe{hello} file{hello.map>: cxx{hello} hxx{hello} hxx{common}
|
|
|
|
|
|
|
