dlang
dlang copied to clipboard
gentoo
dlang-compilers stable mismatch
It appears afcb1ee42c2bd21163a578ca707c123230b5e2b2 stabilized dmd-2.099.1. However, while the ebuild remains stable, 8e3666dcf022b3120ab61ebcf80ee7db5e281a51 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.)
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.
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.
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.