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
