host detection script is broken due to changes in archspec 0.1.3

[boegel]

The archspec.cpu.host function was changed in archspec 0.1.3 (see archspec/archspec#53) to return the best matching generic CPU microarchitecture level if there's no exact match.

These levels are values like x86-64-v4, and have a 'generic' value for vendor, see https://github.com/archspec/archspec-json/pull/31/files.

This causes trouble where we expect to find an actual vendor string like GenuineIntel (which we map to intel) or AuthenticAMD (which we map to amd), for example in det_host_triple in init/eessi_software_subdir_for_host.py or in eessi_software_subdir_for_host.py.

[boegel]

The best way forward here is probably to add support in the archspec API to allow requesting to archspec.cpu.host to return a non-generic microarchitecture level?

[Senui]

The generic value for vendor was already a thing in archspec 0.1.2: #112

Currently, a generic return value ends up in crashing the EESSI initialization script.

[alalazo]

If you just need the vendor, one option is to use:

info = raw_info_dictionary()

directly.

[boegel]

@Senui You're right, but that's a different issue I think (and much easier to fix in the EESSI init scripts)

@alalazo I think the issue is broader than just the vendor part. We'd still end up with something like x86_64/amd/x86_64_v4 then.
What we really want/need is opting out of the generic microarchitecture levels entirely, I think...

[alalazo]

Then you can:

info = raw_info_dictionary()
candidates = compatible_microarchitectures(info)

You'll get a list of compatible targets and you can discard the generic ones.

[boegel]

@alalazo We also want to get the best non-generic compatible target though, which means we'll need to duplicate basically the whole host function and customize it to totally ignore the generic ones.

Wouldn't it make sense to implement support in archspec for host(generic=False), so you can opt-in to totally ignore the generic targets?