| 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 ...
|
| 1c0d0252 | 20-Feb-2024 |
Chris Kay <chris.kay@arm.com> |
build: correct minor toolchain documentation error
Default values for toolchain tools are instead provided by the main toolchain makefile, rather than a parent makefile. This was an oversight from a
build: correct minor toolchain documentation error
Default values for toolchain tools are instead provided by the main toolchain makefile, rather than a parent makefile. This was an oversight from a previous version of the original toolchain refactor patch.
Change-Id: I75752ed7874b36e1c679d94292a2664e234c484b Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| cc277de8 | 20-Oct-2023 |
Chris Kay <chris.kay@arm.com> |
build: refactor toolchain detection
This change refactors how we identify the toolchain, with the ultimate aim of eventually cleaning up the various mechanisms that we employ to configure default to
build: refactor toolchain detection
This change refactors how we identify the toolchain, with the ultimate aim of eventually cleaning up the various mechanisms that we employ to configure default tools, identify the tools in use, and configure toolchain flags.
To do this, we introduce three new concepts in this change:
- Toolchain identifiers, - Tool class identifiers, and - Tool identifiers.
Toolchain identifiers identify a configurable chain of tools targeting one platform/machine/architecture. Today, these are:
- The host machine, which receives the `host` identifier, - The AArch32 architecture, which receives the `aarch32` identifier, and - The AArch64 architecture, which receivs the `aarch64` identifier.
The tools in a toolchain may come from different vendors, and are not necessarily expected to come from one single toolchain distribution. In most cases it is perfectly valid to mix tools from different toolchain distributions, with some exceptions (notably, link-time optimization generally requires the compiler and the linker to be aligned).
Tool class identifiers identify a class (or "role") of a tool. C compilers, assemblers and linkers are all examples of tool classes.
Tool identifiers identify a specific tool recognized and supported by the build system. Every tool that can make up a part of a toolchain must receive a tool identifier.
These new identifiers can be used to retrieve information about the toolchain in a more standardized fashion.
For example, logic in a Makefile that should only execute when the C compiler is GNU GCC can now check the tool identifier for the C compiler in the relevant toolchain:
ifeq ($($(ARCH)-cc-id),gnu-gcc) ... endif
Change-Id: Icc23e43aaa32f4fd01d8187c5202f5012a634e7c Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 3dafd960 | 24-Jan-2024 |
Govindraj Raja <govindraj.raja@arm.com> |
refactor(build): minor updates
Move RME to 9.2 optional features and add minor updates to comments.
Change-Id: I12a4940e82ca5df72af5421ddab43bc6a1628e95 Signed-off-by: Govindraj Raja <govindraj.raj
refactor(build): minor updates
Move RME to 9.2 optional features and add minor updates to comments.
Change-Id: I12a4940e82ca5df72af5421ddab43bc6a1628e95 Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
show more ...
|
| 7275ac2a | 23-Jan-2024 |
Govindraj Raja <govindraj.raja@arm.com> |
fix(build): march handling with arch-features
Currently all march compiler option handling is moved to build utility in march.mk.
We pass arch-features to build which appends to march options, so t
fix(build): march handling with arch-features
Currently all march compiler option handling is moved to build utility in march.mk.
We pass arch-features to build which appends to march options, so this should be done once we decide march options and moving it to march.mk file.
Change-Id: Ifaf99af5f371fd28db376a12657ccf4f363295c2 Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
show more ...
|
| 2a71f163 | 23-Jan-2024 |
Govindraj Raja <govindraj.raja@arm.com> |
refactor(build): refactor mandatory options
Currently we enable all mandatory options for a current MAJOR.MINOR number without considering architecturally to what version the current arch should be
refactor(build): refactor mandatory options
Currently we enable all mandatory options for a current MAJOR.MINOR number without considering architecturally to what version the current arch should be compliant with.
For example Arch v9 should be compliant with 8.5 and shouldn't consider being compliant with 8.9, so refactor FEAT_* handling to ensure we capture and handle compliance correctly.
So refactor to use a list and add FEAT_* which are only compliant with a given arch rather than relying on all the FEAT_* from previous should be enabled for given arch version.
Change-Id: I8b0dd076c168a647de43b8618fbbe607412f7cab Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
show more ...
|
| 6c1ae075 | 11-Jan-2024 |
Govindraj Raja <govindraj.raja@arm.com> |
refactor(build): allow mandatory feats disabling
Currently any arch FEAT_* can be enabled from: - command line build options - platform makefile - from arch_features.mk
These are in order. Howev
refactor(build): allow mandatory feats disabling
Currently any arch FEAT_* can be enabled from: - command line build options - platform makefile - from arch_features.mk
These are in order. However, mandatory features are enforced from arch_features.mk and platform makefile can't override them.
Allow command line options or platforms makefile to disable any mandatory features.
Change-Id: I6fdca1a3d0b405a88cd7a20309e0c1eecd57a650 Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
show more ...
|