A rewrite of dlang.eclass in the python-r1.eclass style which seems to be the de-facto in ::gentoo. I've tried to keep as much of the features of the old eclass so the porting of the ebuilds would involve minimal hassle.
The choice between dlang_single_target and dlang_targets is whether a package supports being installed for multiple dlang implementations simultaneously. Practically, all of the ebuilds use dlang_single_target with the exception of gtkd which uses dlang_targets.
for the developers
With this rewrite I've tried to move away from overwriting variables in the eclass to specify the state to be built and instead use new variables and have the ebuilds use those values to correctly tell the build systems what to do. Notably, $LIBDIR and $LDFLAGS are no longer overwritten the former is mostly replaced by dlang_dolib and the latter is replaced by $DLANG_LDFLAGS. The final result is that ebuilds have to write a little bit more code but the variable-flow is much easier to follow.
At the same time, I've tried to break up the logic of DLANG_PACKAGE_TYPE that was used in dlang.eclass to pick between what is now dlang-r1.eclass and dlang-single.eclass and split it between common logic that is best put in dlang-utils.eclass and the multilib logic bits. My goal with the latter ones was to have them be independent of the eclasses, as in, if an ebuild didn't want multilib it would just inherit dlang but if it wanted it would do inherit dlang multilib, in short, I wanted the dlang eclasses to work mostly as a plugin to existent functionality. I think I've gotten close but not exactly there. In dlang-r1.eclass_dlang_multibuild_wrapper sets up the environment in ${T}/${MULTIBUILD_ID} instead of in ${T}/${MULTIBUILD_VARIANT} which was what python-r1 used. This is because this environment is dependent on $ABI so, since speaking theoretically is not really useful when there is a single package which uses this eclass, gtkd needs to have the environment generated for each DLANG_MULTIBUILD_VARIANT x MULTILIB_MULTIBUILD_VARIANT. This is a harmless enough assumption so I'll consider the goal reached.
DLANG_PACKAGE_TYPE=dmd has also been removed as the eclasses provide enough functionality to express this edge case.
breaking changes
On x86, dlang.eclass set the library directory of ldc2 to /usr/lib/ldc2/*/lib32. This is not correct as the correct directory should be the one returned by $(get_libdir) so it should be plain lib. This has been corrected but now there is a situation in which gtkd will not be found unless rebuilt (due to being in the wrong directory). Hopefully this doesn't happen, and if it does the fix is to rebuild gtkd.
not so breaking changes
dev-util/dcd no longer references /usr/lib/ldc2/*/include/d/ldc as one of the import paths.
the linker flag for ldc2 has become -L from -L=
-op is no longer added to LDCFLAGS (in the eclass)
A rewrite of dlang.eclass in the python-r1.eclass style which seems to be the de-facto in ::gentoo. I've tried to keep as much of the features of the old eclass so the porting of the ebuilds would involve minimal hassle.
A summary of changes:
for the users
The choice between dlang_single_target and dlang_targets is whether a package supports being installed for multiple dlang implementations simultaneously. Practically, all of the ebuilds use dlang_single_target with the exception of gtkd which uses dlang_targets.
for the developers
With this rewrite I've tried to move away from overwriting variables in the eclass to specify the state to be built and instead use new variables and have the ebuilds use those values to correctly tell the build systems what to do. Notably, $LIBDIR and $LDFLAGS are no longer overwritten the former is mostly replaced by dlang_dolib and the latter is replaced by $DLANG_LDFLAGS. The final result is that ebuilds have to write a little bit more code but the variable-flow is much easier to follow.
At the same time, I've tried to break up the logic of
DLANG_PACKAGE_TYPEthat was used indlang.eclassto pick between what is nowdlang-r1.eclassanddlang-single.eclassand split it between common logic that is best put indlang-utils.eclassand the multilib logic bits. My goal with the latter ones was to have them be independent of the eclasses, as in, if an ebuild didn't want multilib it would justinherit dlangbut if it wanted it would doinherit dlang multilib, in short, I wanted the dlang eclasses to work mostly as a plugin to existent functionality. I think I've gotten close but not exactly there. Indlang-r1.eclass_dlang_multibuild_wrappersets up the environment in${T}/${MULTIBUILD_ID}instead of in${T}/${MULTIBUILD_VARIANT}which was whatpython-r1used. This is because this environment is dependent on$ABIso, since speaking theoretically is not really useful when there is a single package which uses this eclass, gtkd needs to have the environment generated for eachDLANG_MULTIBUILD_VARIANT x MULTILIB_MULTIBUILD_VARIANT. This is a harmless enough assumption so I'll consider the goal reached.DLANG_PACKAGE_TYPE=dmdhas also been removed as the eclasses provide enough functionality to express this edge case.breaking changes
On x86, dlang.eclass set the library directory of ldc2 to /usr/lib/ldc2/*/lib32. This is not correct as the correct directory should be the one returned by
$(get_libdir)so it should be plain lib. This has been corrected but now there is a situation in which gtkd will not be found unless rebuilt (due to being in the wrong directory). Hopefully this doesn't happen, and if it does the fix is to rebuild gtkd.not so breaking changes
-Lfrom-L=-opis no longer added to LDCFLAGS (in the eclass)