search

gentoo / dlang

[MIRROR] D programming language ebuild repository
https://gitweb.gentoo.org/repo/user/dlang.git
GNU General Public License v2.0
30 stars 25 forks source link

dlang-compilers stable mismatch #109

Open doctaweeks opened 1 year ago

doctaweeks commented 1 year ago

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.)

the-horo commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.