eessi_software_subdir_for_host.py will need to be changed once archspec pr is merged

[migueldiascosta]

once archspec/archspec#53 is merged, eessi_software_subdir_for_host.py will need to be slightly modified because archspec in some circunstances will detect a generic architecture (e.g. x86_64_v3) with a generic vendor string, which will need to be added to VENDOR_MAP (otherwise host_vendor will be None, tripping the os.path.join in find_best_target)

EDIT: Once that is done, eessi_software_subdir_for_host.py will continue to fallback to x86_64/generic if it can't find a compatible target.

[migueldiascosta]

further discussion: I would suggest than when a generic architecture is detected by archspec, eessi_software_subdir_for_host.py would ouput a message with the closest but not strictly compatible match (e.g., in the case of x86_64_v3 it would be haswell) and noting that users can set EESSI_SOFTWARE_SUBDIR_OVERRIDE, at their own risk

In this situation at least one feature (e.g. aes) of the not strictly compatible closest match will not be present/enabled in the host cpu, but if that feature isn't actually used, overriding allows making good use of everything else (in particular, the correct avx level)

Of course, if EESSI moves to using the generic levels as targets instead of the vendor specific ones (which would require not building with native but with the host's highest generic level instead), then this would be no longer an issue and each EESSI target would be compatible with more host cpus, while still making use of the most important features, performance wise, in each level, at the cost of not making use of (less important, performance wise, imh(and speculative)o) vendor specific features...