Thoughts about D package management on Gentoo

[Wyatt]

I'm falling asleep here, but before I go...

On Saturday, 9 November 2013 at 00:38:16 UTC, Marco Leise wrote:
>
> "dub" which don't integrate with the official package
> managers.
>
With the right functionality, we could do this similarly to how 
we hook CPAN.pm for g-cpan.  If nothing else, it could be done a 
damn sight more reliably than Diego's gem eclass if we get this 
squared away sooner than later.  (This is a weird space, though.)

> When I decide to install a D application on Gentoo, I want it
> to just work. For Gentoo that includes the choice of compiler
> to build it and the used compilation flags.
>
> The package manager should handle installing LLVM, the latest
> stable LDC and required libraries on top of that and finally
> the application.
>
For a long time, GDC was just a USE flag on GCC.  Not sure what 
the current state is because I've been trying to ignore the sad 
state of our D packaging in hopes that it would go away.  (How 
many D overlays have we killed at this point anyway?)

> - Compiler and library are closely coupled and depend on each
>   other.

So we'll need a virtual for "the D implementation"?  cf. 
virtual/package-manager and dozens of others.

> - Each new D point release brings a new, generally
>   incompatible standard library.

Unless I've misunderstood completely, the compiler, runtime, and 
standard library are ostensibly separable, but for the 
foreseeable future they need to be revbumped in lockstep for this 
reason.  No biggie.  cf. kde-base/*

> - All three major compiler backends are in good shape and use.
>   But their generated code is not exchangeable (as far as
>   I've heard due to ABI differences).

Do they? I thought this had been worked out.

> - Tools tend to expect that "dmd" is available as a command.
>
Which tools?  Quantify the problem, and we may be able to fix it. 
(We have like all of upstream right here...;)

> To deal with the complexity of package dependency management
> in this scenario, we need to be able to install multiple
> versions of D compilers in parallel (similar to what dvm does).

Do we really?  Not necessarily disagreeing, but I think this 
needs substantiation.

> This can be accomplished by so called "slots" for each point
> release. We can do this for all three compilers and will end
> up with binaries like "dmd2.064" and "gdc2.063".
>
See, I'd like to avoid the awful version creep we see with GCC-- 
that only exists because we're trying to provide an upgrade path 
for lazy people who never upgrade (never mind that it's never 
really worked well).  Thankfully RAP may finally be fixing that, 
now that Benda is joining the toolchain herd.

> Next a symlink should be established to the current
> implementation of dmd, e.g.: /bin/dmd -> /bin/ldmd2.
> This symlink could be managed with an eselect plugin as it is
> already done for other languages like Python or the Java
> Runtime.
>
I'm so not fond of those, but it looks like we may not have a 
choice.  Do we have any use for an env.d entry here?

> Since libraries for D depend not only on druntime/Phobos, but
> also on the compiler the Gentoo user should be able to setup
> globally and for each library which compilers it should work
> with.

It's way too early for this shade of bikeshedding.  Let's see 
about actually getting packages in the tree, first.  (The 
approach may or may not be a good fit.  I think we should give it 
some time to settle first, though.)

-Wyatt