Add gdc-11.3.0

[the-horo]

Bump the version for gdmd and gdc_frontend in dlang-compilers.eclass.

However, in order to use it to build dmd, some little changes had to be done to dmd.eclass. dlang_compile_bin has $DCFLAGS tied to $DC, so if we used the gdmd wrapper instead of gdc it would error saying that there are unknown options. Another particularity for dlang_compile_bin is that, in the case of gdc, it does not create the directory in which to put the output file, and one has to create it manually; as opposed to ldc and dmd which will create the needed directory(s).

One more thing needed to be changed, in dlang.eclass there is a line in which -shared-libphobos is added to $DCFLAGS when the compiler is gdc. If, during the building of dmd by the build.d script, gdc does not receive this flag, there will be linker errors, thus this has to be provided, through several layers of indirection: -q, prefix since build.d uses the gdmd wrapper; and build.d DFLAGS=$DCFLAGS since the script doesn't pick environment DFLAGS, they have to be given as args like in this line.

Though now gdc works as a build compiler for dmd I am not quite satisfied with the current situation:

1. shouldn't dlang_compile_bin be compiler agnostic and create the directory for the output file?
2. GDCFIX is just a dirty fix, what I think I should have done is go through DCFLAGS for each compiler (ldc and gdc really) and have it transformed to something their respective dmd wrapper would understand and have it passed to build.d
3. -shared-libphobos doesn't sound like a flag that one would want in every build, though I have no idea what it even does

The changes above I think I'm qualified to implement myself, so I'm just asking for opinions on whether the changes make sense.

One question before this gets merged. I don't know what keywords I am supposed to put for gdc in dlang-compilers.eclass. Should they be all unstable, the same as those of gcc, or is there some upstream reference that documents it?

[mleise]

The keywords for gcc were just copied from the lastest ebuild. They are generally necessary because unlike other packages, the ones in dlang directly depend on a compiler (selected via USE-flag) and said compiler cannot be keyworded when the package in question is not. A stable package cannot depend on an unstable one. I had to strip some arch KEYWORDS though. For example there is one for which the d USE-flag to gcc is masked. You'll see it when you run repoman full -d on the full set. So essentially: Copy keywords from gcc, then remove the ones that give errors. As for your questions:

1. Probably, yes. Either I didn't need it at the time or couldn't figure out how to reliably pin down the output directory. Anyways for the ebuilds that use it, like dscanner I just created the bin directory in src_prepare().
3. It was very late in the development that GDC was able to produce shared libraries. Back in the days everything was linked statically and it remained the default. It was also the case that the ABI was very much in flux, so there was not much incentive to create shared libraries if you can't call them with the next version of the compiler. Since it is the standard for C/C++ to dynamically link the runtime library, only a few packages coming as static libraries (USE=static-libs) and personal preference, I tried to make dynamic linking the default for Dlang, too. From the work on GtkD and Tilix, I vaguely remember that the decision is all or nothing with GDC. Either all linked libraries are static or all are dynamic. Maybe I misremember.