Most developers run the `clean`, `checkpatch` and other similar targets
without specifying any other additional build options. When combined
with a flow where the developer passes `CROSS_COMPILE` or `CC`
explicitly, and where the default-configured tools are not on the PATH,
these targets will warn about unrecognized toolchain tools.
This change is a workaround for this whereby the toolchain makefile is
not expanded unless a target *not* named `*clean`, `check*` `doc` or
`*tool` has been specified.
Change-Id: I2f2a275964b65253df07c2207043217b14f615fe
Signed-off-by: Chris Kay <chris.kay@arm.com>
The toolchain refactor change introduces the `${toolchain}-${tool}-id`
variables, which provide identifiers for all of the toolchain tools used
by the build system. This change replaces the various conditions that
are in use to identify these tools based on the path with a standard set
of comparisons against these new identifier variables.
Change-Id: Ib60e592359fa6e415c19a012e68d660f87436ca7
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change migrates the values of `CC`, `CPP`, `AS` and other toolchain
variables to the new `$(toolchain)-$(tool)` variables, which were
introduced by the toolchain refactor patch. These variables should be
equivalent to the values that they're replacing.
Change-Id: I644fe4ce82ef1894bed129ddb4b6ab94fb04985d
Signed-off-by: Chris Kay <chris.kay@arm.com>
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>
Current build infra uses ARM_ARCH_MAJOR/MINOR to come up with march
version and uses that march version with the compiler.
However in certain situations this is not ideal, like for example when
we build with gcc-11 which supports only till march=armv8.5 but
we need to build for 8.8 build, this means we need to bump down
MAJOR/MINOR and we can't rely on major and minor values from the
platform to select march value and build infra doesn't even try
to compile and fails with not supported MAJOR/MINOR.
By adding a march build helper we try to check if compiler supports
given march value from MAJOR/MINOR values from platform, if compiler
doesn't support then we try to check what's the max or best supported
march version by compiler and choose that march value and try to
compile with that.
This is a supportive mechanism which will decouple march reliance on
MAJOR/MINOR values from platform and will pave way for setting up
enabling of features based on MAJOR/MINOR without worrying about the
compiler not supporting given MAJOR/MINOR.
Also in TF-A we use generic instructions without much reliance or need
for exact march necessity. So enabling and building features from
armv-8.8 using an armv-8.5 march value is still going to be fine.
Please note: Platforms are free to freeze their march values using
`MARCH_DIRECTIVE`. In absence of this define we are going to poke
the compiler and come up with a potential march value.
Change-Id: I673061a269ec9018ff12e75dc375979f5e33b7d1
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
