Thoughts about D package management on Gentoo

[Marco Leise]

Am Sat, 09 Nov 2013 08:42:59 +0100
schrieb "Chris Nicholson-Sauls" <ibisbasenji at gmail.com>:

> I think you're headed the right way, and I'd recommend studying 
> how Ruby/rubygems are handled in Gentoo.  A similar pattern, with 
> eselect, a set of symlinks, and versioned package directories, 
> would do an awful lot.  One may end up with a mass of installed 
> slots, but that sort of problem is usually resolved over time.

Quite a few languages use similar schemes. Even "equery f gcc"
can server as a guide. But reusing the gcc ebuild is not that
simple. I can't easily remove the other language USE flags from
gcc for gdc and the build process takes an awful long time.
On the positive side, it was relatively easy to "mixin" the
GDC code from Github though from a specific branch and commit.

> One thing of benefit, assuming it's being applied properly by all 
> vendors, is the availability of std.compiler and a few predefined 
> version identifiers so that D programs can already check what 
> compiler and version they are being processed by.  This saves the 
> trouble of trying to establish a USE flag convention for that.

The .d files can, but the build tools need an environment
variable (lets call it DC) to find the active D compiler. You
can change the C compiler for Clang or ICC on Gentoo. This
scheme should be adopted for D, too.

This is what really worries me:
Assuming my current compiler (through eselect or other means)
is dmd-2.063. Now I emerge "apps-office/cool-d-application"
which uses GtkD. That means that I have to establish a
dependency on GtkD compiled with dmd-2.063. How would I do
that without naively introducing one use flag per compiler and
release?
You said, look at Ruby and it ebuilds do exactly that:
USE_RUBY="ruby18 ruby19 ree18 jruby"
A list of language implementations and versions.

> In light of trying to support different compilers, it might be a 
> good idea to have a virtual/dmd (or virtual/dc? or...?) package 
> to provide dependency genericity.  I know you mentioned having a 
> virtual/phobos package, but I'm not sure that's safe -- yet.  
> Once we are at a stage where dynamic libraries work well enough 
> that phobos is normally used as such, then it would make more 
> sense.

It actually is a virtual/dc under the hood. The idea was that
it is the Phobos API that changes often, not the compiler ABI.
I would name it virtual/dlang for what it's worth. :D

-- 
Marco