| 7c4e1eea | 02-May-2024 |
Chris Kay <chris.kay@arm.com> |
build: unify verbosity handling
This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.
The `silent` and `verbose` variables
build: unify verbosity handling
This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.
The `silent` and `verbose` variables are boolean values determining
whether the build system has been configured to run silently or
verbosely respectively (i.e. with `--silent` or `V=1`).
These two modes cannot be used together - if `silent` is truthy then
`verbose` is always falsy. As such:
make --silent V=1
... results in a silent build.
In addition to these boolean variables, we also introduce two new
variables - `s` and `q` - for use in rule recipes to conditionally
suppress the output of commands.
When building silently, `s` expands to a value which disables the
command that follows, and `q` expands to a value which supppresses
echoing of the command:
$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed but not echoed'
When building verbosely, `s` expands to a value which disables the
command that follows, and `q` expands to nothing:
$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed and echoed'
In all other cases, both `s` and `q` expand to a value which suppresses
echoing of the command that follows:
$(s)echo 'This command is executed but not echoed'
$(q)echo 'This command is executed but not echoed'
The `s` variable is predominantly useful for `echo` commands, where you
always want to suppress echoing of the command itself, whilst `q` is
more useful for all other commands.
Change-Id: I8d8ff6ed714d3cb401946c52955887ed7dca602b
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 0dfa3dea | 29-May-2024 |
Chris Kay <chris.kay@arm.com> |
build: add facilities for interpreting boolean values
This is another small addition to the build system utlities to make it
easier to determine the truthiness of an arbitrary value.
This change ad
build: add facilities for interpreting boolean values
This is another small addition to the build system utlities to make it
easier to determine the truthiness of an arbitrary value.
This change adds the `bool` function, which takes a value and determines
whether the value is "truthy". We consider a value to be truthy if it is
NOT one of: "0", "n", "no", "f" or "false" (all case-insensitive).
If the value is truthy then it is returned as-is. Otherwise, no value
is returned.
Change-Id: I19347f4c3ae00a6b448514a28cc2d9d06f683f25
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| e01c7126 | 15-May-2024 |
Chris Kay <chris.kay@arm.com> |
build: allow shell commands in `CC` and friends
When we added support for paths with spaces in the `CC`, `LD`, `AR`,
etc. variables in a previous patch, we explicitly broke support for
compiler laun
build: allow shell commands in `CC` and friends
When we added support for paths with spaces in the `CC`, `LD`, `AR`,
etc. variables in a previous patch, we explicitly broke support for
compiler launchers like `ccache`, which is usually used by prepending it
to `CC`, e.g. `CC='ccache gcc'`. This patch modifies the toolchain
detection logic to avoid sanitizing the toolchain variables for the
shell unless we are confident that they represent a path to the program
(i.e. that `which $(CC)` resolves to something).
Change-Id: I942d09cfc462d50ed07c5d22434b0275c22d1522
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 3d6c7e59 | 16-Apr-2024 |
Chris Kay <chris.kay@arm.com> |
build: improve diagnostics for unrecognized toolchain tools
Up until recently the build system accepted an arbitrary value for `AS`
and, unbeknownst to anybody, was simply not making use of it. Rece
build: improve diagnostics for unrecognized toolchain tools
Up until recently the build system accepted an arbitrary value for `AS`
and, unbeknownst to anybody, was simply not making use of it. Recent
feedback has revealed that a number of contributors have `AS` explicitly
configured to use the GNU assembler, which is not a supported assembler,
and this breakage has yielded some cryptic error messages, e.g.:
aarch64-none-elf-as: unrecognized option '-x'
This change introduces human-readable diagnostics to help developers
with diagnosing unsupported toolchain tools:
The configured AArch64 assembler could not be identified and may not
be supported:
aarch64-none-elf-as
The default AArch64 assembler is:
aarch64-none-elf-gcc
The following tools are supported:
- Arm® Compiler for Embedded `armclang`
- LLVM Clang (`clang`)
- GNU GCC (`gcc`)
The build system will treat this assembler as GNU GCC (`gcc`).
Change-Id: I316036c83be2d45ee83a88846cf65c6ce7ae3c26
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 7b453526 | 08-Mar-2024 |
Chris Kay <chris.kay@arm.com> |
build: separate preprocessing from DTB compilation
This is a small change to separate preprocessing of device tree sources
into their own build step as opposed to combining them. The impact of
this
build: separate preprocessing from DTB compilation
This is a small change to separate preprocessing of device tree sources
into their own build step as opposed to combining them. The impact of
this is more on separation of concerns than anything tangible, but it's
helpful to avoid doing more than necessary in a build rule.
Change-Id: I770291bd9d9f627c93e82556a40f753bf27eef93
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 4731c00b | 09-Apr-2024 |
Chris Kay <chris.kay@arm.com> |
fix(build): wrap toolchain paths in double quotes
Fix issue with Windows paths containing spaces. Recent toolchain
refactoring (cc277de) caused a regression in the Windows build. Ensure
toolchain pa
fix(build): wrap toolchain paths in double quotes
Fix issue with Windows paths containing spaces. Recent toolchain
refactoring (cc277de) caused a regression in the Windows build. Ensure
toolchain path utilities wrap paths in double quoted strings.
Change-Id: I7a136e459d85cff1e9851aedf0a5272a841df09c
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Signed-off-by: Chris Kay <chris.kay@arm.com>
Co-authored-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| b9014f85 | 12-Mar-2024 |
Ahmad Fatoum <a.fatoum@pengutronix.de> |
feat(build): redirect stdin to nul during toolchain detection
It's common for Makefiles to use variables like CC, AS or LD instead of
hardcoding the name of binaries. These can be defined by the use
feat(build): redirect stdin to nul during toolchain detection
It's common for Makefiles to use variables like CC, AS or LD instead of
hardcoding the name of binaries. These can be defined by the user to
use a differnet toolchain or even as a crutch to enable cross-compilation.
In TF-A, this is not needed, as support for cross-compilation is baked
in via the CROSS_COMPILE option. TF-A still defined AS for its internal
use, but unlike most other projects, the default was setting it to the C
compiler. Overriding it wasn't possible from the environment though,
only as a make argument, so this didn't cause much issue.
With commit cc277de81692 ("build: refactor toolchain detection"), AS can
now also be set from the environment. This breaks any scripts that
supply make with a cross environment that sets AS to an assembler.
Doing so was without effect before, but now leads to a quite ugly failure
mode: As TF-A now tries to detect the toolchain, it will call AS with the
option -v, which for GNU as(1) prints the version, but doesn't exit.
Thus, as(1) will continue waiting on stdin input and the build hangs
without much indication what's wrong.
Avoid this failure mode by ensuring any tool that attempts to read stdin
during toolchain detection will immediately get EOF and exit, leading to
an error message later on instead of the build hang.
Change-Id: I79a84961f5a69250292caa7f9e879a65be4bd9f2
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
show more ...
|