Standardize "platform names" for non-x86 architectures

[t-sommer]

Currently the MLS (3.7-dev, p. 205) defines only "platform names" for x86 and x86_64 on Windows and Linux:

– "win32" (Microsoft Windows 32 bit)
– "win64" (Microsoft Windows 64 bit)
– "linux32" (Linux Intel 32 bit)
– "linux64" (Linux Intel 64 bit)

I suggest to adopt the platform tuple of FMI 3.0 to support other architectures and operating systems (e.g. macOS on Apple Silicon and Windows on ARM).

[maltelenz]

#2220

[HansOlsson]

The platform tuple is a flat format - which for will make it somewhat messy, especially for different ABI-versions.
In addition it is somewhat unclear how to efficiently handle different ABI-versions if you have multiple libraries.

If you have two libraries: one that need different versions for different ABI-versions and one that doesn't; do you have to duplicate the one that doesn't or are both library-directories added to the library-path?

ABI-versions are also often more complicated when it matter - VS 2022 is generally binary backwards compatible with VS 2015; but there was a major ABI-break between 2015 and 2012 (and VS 2012 had a minor but most annoying C-API breaking change). I assume there are similar considerations for gcc.

[DagBruck]

Really, some organization with more authority on the topic than MA should already have decided such a naming convention? Let's just steal something and point to the source.

[DagBruck]

I assume there are similar considerations for gcc.

Well, at least we have the problem with different Linux kernels and libc, although the issues for complete applications with GUI seem more complicated.