| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
Specifically, we need to check whether the prerequisite_member is ad hoc
before checking whether it is NULL because ad hoc ones are blanked out (set to
NULL) during execute.
|
|
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)"
|
|
|
|
|
|
|
|
|
|
This makes sure we get different targets for different toolchains.
|
|
Now it is c/cxx first followed by cc which is the reverse order of coptions
since the header/library search paths are examined in the order specified (in
contrast to the "last value wins" semantics that we assume for coptions).
|
|
|
|
|
|
|
|
|
|
|
