The Yocto team has requested that we do not use Poetry from within the
Makefile, as Yocto does not have network access during the build
process.
We want to maintain the current behaviour, so this change makes our use
of Poetry contigent on it being available in the environment.
Additionally, explicitly passing an empty toolchain parameter now allows
a tool to be *disabled* (e.g. passing `POETRY=` will prevent the build
system from trying to use Poetry).
Change-Id: Ibf552a3fee1eaadee767a1b948b559700083b401
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change enables a fairly commonly-requested use-case, which is to
fall back to the host system's native toolchain when building on AArch64
if the bare-metal toolchain is not available.
In this situation, if the `aarch64-none-elf` GCC toolchain cannot be
located, the build system will look for `aarch64-linux-gnu` before
giving up.
Change-Id: I39d2a8837b651b28cf0eafa92f6003a7f66767a0
Signed-off-by: Chris Kay <chris.kay@arm.com>
Since the introduction of the toolchain detection framework into the
build system, we have done determination and identification of the
toolchain(s) used for the build at the initialization of the build
system.
This incurs a large cost to the build every time - for every toolchain
that has been requested by the current makefile, we try to identify each
tool in the list of known tool classes, even if that tool doesn't
actually see any use.
For the clean and check-like targets we worked around this by disabling
most of the toolchains if we detect these targets, but this is
inflexible and not very reliable, and it still means that when building
normal targets we are incurring that cost for all tools whether they are
used or not.
This change instead modifies the toolchain detection framework to only
initialize a tool for a given toolchain when it is first used. This does
mean that we can no longer warn about an incorrectly-configured
toolchain at the beginning of build system invocation, but it has the
advantage of substantially reducing build time and the complexity of
*using* the framework (at the cost of an increase in complexity in the
framework itself).
Change-Id: I7f3d06b2eb58c1b26a846791a13b0037f32c8013
Signed-off-by: Chris Kay <chris.kay@arm.com>
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>
When configuring GNU GCC as the C compiler, we usually use the GNU BFD
linker directly to link by default. However, this complicates things
because we also need to support LTO, which can only be done when linking
is done via the C compiler, and we cannot change the linker later on if
some other part of the build system wants to enable LTO.
This change migrates the default choice of linker to GCC if the C
compiler is GCC, in order to enable this use-case. This should have no
impact on anything outside of the build system, as by default GCC merely
acts as a wrapper around BFD.
Change-Id: I40771be2b0571def67bbfde9e877e7629ec8cdaa
Signed-off-by: Chris Kay <chris.kay@arm.com>
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>
