| #
d6dccfb0 |
| 20-Jan-2025 |
Manish Pandey <manish.pandey2@arm.com> |
Merge "build: remove Windows compatibility layer" into integration
|
| #
c3273703 |
| 13-Jan-2025 |
Chris Kay <chris.kay@arm.com> |
build: remove Windows compatibility layer
For a couple of releases now we have officially withdrawn support for building TF-A on Windows using the native environment, relying instead on POSIX emulat
build: remove Windows compatibility layer
For a couple of releases now we have officially withdrawn support for building TF-A on Windows using the native environment, relying instead on POSIX emulation layers like MSYS2, Mingw64, Cygwin or WSL.
This change removes the remainder of the OS compatibility layer entirely, and migrates the build system over to explicitly relying on a POSIX environment.
Change-Id: I8fb60d998162422e958009afd17eab826e3bc39b Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| #
7ea8852e |
| 08-Nov-2024 |
Yann Gautier <yann.gautier@st.com> |
Merge changes If56ed0ab,I632236a1 into integration
* changes: perf(build): don't check the compiler's flags for every target perf(build): be clever about uppercasing
|
| #
f7a41fb4 |
| 10-Oct-2024 |
Boyan Karatotev <boyan.karatotev@arm.com> |
perf(build): be clever about uppercasing
Most of the macros in build_macros.mk get lazily evaluated. That's mostly fine, except for the fact that the `uppercase` macro needs to spawn a subshell to g
perf(build): be clever about uppercasing
Most of the macros in build_macros.mk get lazily evaluated. That's mostly fine, except for the fact that the `uppercase` macro needs to spawn a subshell to get its output. And the target for every file requires calling `uppercase` many, MANY, times, thrashing performance on even the most trivial of make commands.
We can be a little clever and only call `uppercase` a handful of times and then pass around the already uppercased strings.
The same is true about the verbosity augmentation variables. Simply changing them to simply expanded variables allows for them to be pre-processed and then used over and over again.
`make realclean` is a pretty good benchmark for this as it doesn't do much else but must process all the rules, like every other make command. On a clean checkout of TF-A on an Intel Xeon Gold 5218 (i.e. slow single-core) workstation, that command used to take about 7 seconds. With this patch it takes about 0.5.
Change-Id: I632236a12a40f169e834974ecbc73ff80aac3462 Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
cd8eb18d |
| 17-Jun-2024 |
Manish Pandey <manish.pandey2@arm.com> |
Merge changes from topic "ck/tf-a/verbosity-cleanup" into integration
* changes: build: unify verbosity handling build: add facilities for interpreting boolean values build: add string casing
Merge changes from topic "ck/tf-a/verbosity-cleanup" into integration
* changes: build: unify verbosity handling build: add facilities for interpreting boolean values build: add string casing facilities to utilities
show more ...
|
| #
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 ...
|