dlang-compilers stable mismatch

[doctaweeks]

It appears afcb1ee stabilized dmd-2.099.1. However, while the ebuild remains stable, 8e3666d effectively destabilized dmd-2.099.1 in the dlang-compilers map but I'm not sure it was intentional. Regardless, there is a mismatch between the ebuild and the map and it leads to confusing errors when attempting to emerge/update dlang-tools with USE=dmd-2_099 on amd64. (This also applies to dmd 2.097 and 2.098.)

[the-horo]

Thank you for reporting, fixed by #111.

The error isn't happening because of the mismatch, it is happening because you are trying to use an unstable compiler (as denoted by dlang-compilers.eclass) to build a stable package. You will get the same result with, let's say, USE=ldc2-1_30.

[doctaweeks]

You will get the same result with, let's say, USE=ldc2-1_30

Yes, but this is not the same case because the dev-lang/ldc2-1.30.0 ebuild is still unstable.

mismatch [...] leads to confusing errors

The mismatch was not the direct cause but if a compiler ebuild is marked stable then it's reasonable to expect that any package can use it as a stable compiler. That wasn't the behavior due to the mismatch.

This is a fragile approach - requiring manually keeping the dlang-compilers.eclass map and the ebuild keywords/stability in sync.

[the-horo]

Yes, but this is not the same case because the dev-lang/ldc2-1.30.0 ebuild is still unstable.

The way it is currently implemented, all the logic that goes behind what can be considered a valid compiler for a certain architecture is based solely on dlang-compilers.eclass since there is no better way, that I am aware of, to get the KEYWORDS variable from a certain ebuild.

This is a fragile approach - requiring manually keeping the dlang-compilers.eclass map and the ebuild keywords/stability in sync.

As shown by this exact issue, this is indeed error prone, yet there is no alternative. The only improvement I can think of is to add a script that does the checking automatically to catch the human errors. And if we do that, maybe do the same thing for profiles/use.desc since both of these 2 files are tied to the ebuilds for the 3 D compilers, as mentioned in the README.