Framework: enhance unsupported archs handling

[hgy59]

Description

While working on another package using dotnet (ombi) this is intended to remove specific archs from generic archs.
i.e. remove unsupported armv7 archs from packages built for armv7.

• remove unsupported archs from generic archs in arch list of spk packages
• introduce Makefile variable UNSUPPORTED_ARCHS_TCVERSION to define arch-tcversion tuples as unsupported
• define DOTNET_UNSUPPORTED_ARCHS to be used in packages depending on dotnet

Related issues:

• Dotnet runtime: remove unsupported archs #5301

Type of change

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[hgy59]

@th0ma7, @publicarray your opinions are welcome.

[th0ma7]

I wanted to do almost exactly that for ffmpeg a while ago. The slight difference being that the intent was to, similar to this, 1) filter out or in specific archs from generic archs (like older or newer from x86_64 archs) so i can then 2) generate individual arch specific packages with needed optimizations (or to the contrary without any).

So the view was not to mark as unsupported but rather only to make sure arch abc is not part of generic arch xyz when uploading online, allowing me to generate and upload individual arch specific packages without conflicting at upload time.

So with this in mind the tiny twist i would suggest is renaming the variable to something like FILTER_OUT_FROM_SPK (and optionally also allow FILTER_IN_FROM_SPK) and then not be blocking from manually building filtered individual archs.

Just my two cents, cheers!

[hgy59]

So with this in mind the tiny twist i would suggest is renaming the variable to something like FILTER_OUT_FROM_SPK (and optionally also allow FILTER_IN_FROM_SPK) and then not be blocking from manually building filtered individual archs.

This is a different approach and there is nothing to rename.
The primary target is that when arch a1 is not supported, we want to exclude a1 from generic arch containing a1.

A variable like FILTER_OUT_FROM_SPK must be applied on generic archs only, or it will have the same effect as UNSUPPORTED_ARCHS. Therefore I would name such a variable REMOVE_FROM_GENERIC_ARCHS

---

A variable like FILTER_IN_FROM_SPK is a different approach at all. As far as I understand this would be like a grouping of archs to a kind of generic arch.
This is not possible with a single variable as we must define something like:
if we build for arch a1 then include archs a2 a3 a.. in the spk

Further more we must ensure that each arch is only in one package (per revision) otherwise it is not possible to uploaded to the repository.
Finally this is not an option we should define in spk Makefiles but rather use a variable that goes to the command line (or environment or local.mk) like:
make arch-apollolake-7.0 PACKAGE_ARCHS="apollolake geminilake denverton"
With such a variable the current generic make arch-x64-7.0 would generate the same result as
make arch-apollolake-7.0 PACKAGE_ARCHS="apollolake avoton braswell broadwell broadwellnk bromolow cedarview denverton dockerx64 geminilake grantley purley kvmx64 v1000 x86 x86_64" except that the spk file has x64 vs. apollolake in the name.

[hgy59]

@th0ma7 first step: I have introduced variable REMOVE_FROM_GENERIC_ARCHS

[hgy59]

@th0ma7 finally added SPK_PACKAGE_ARCHS to overwrite the arch list in spk file.
It is by intention to explicitly set the list and not include the toolchain arch by default.
So you can use the build toolchain of one arch to build a package for different archs (and probably disable optimization or something like that).

[th0ma7]

That's awesome, good job!

[hgy59]

I postpone documentation of REMOVE_FROM_GENERIC_ARCHS and SPK_PACKAGE_ARCHS variables in the wiki until we have a real example (maybe with ffmpeg).