www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thoughts about D package management on Gentoo

reply Marco Leise <Marco.Leise gmx.de> writes:
What is the motivation?

D package management on Gentoo doesn't exist de facto. There
are spread out ebuilds (package manager scripts) for dmd and
ldc and that's it. Orthogonal to that are projects like Jacob
Carlborg's "dvm", which only handles dmd and S=C3=B6nke Ludwig's
"dub" which don't integrate with the official package
managers.

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. Just like it is for most other main stream
languages right now. If you think this is a good thing to
have, please read on...


---(The following is rather Gentoo specific)---

I tried to plot in my head what D support in Gentoo would
ideally look like. Some corners I have found are:

- The makefiles are still not typical, although I don't have
  to patch them anymore since 2.062, which is positive.
- Compiler and library are closely coupled and depend on each
  other.
- Each new D point release brings a new, generally
  incompatible standard library.
- 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).
- Tools tend to expect that "dmd" is available as a command.

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).
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".

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.

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. Again there is prior work on Gentoo for supporting a
list of things (Apache modules, graphics cards, cameras, ...).
The environment variables that are used for that usually go
into /etc/make.conf: D_COMPILERS=3D"dmd gdc ldc" and are mapped
to regular "Use-Flags" for packages, i.e. d_compilers_dmd,
d_compilers_gdc and d_compilers_ldc. (This step is already
automated.)

The libraries could depend directly on an installation of the
respective compilers, but I think it would be cleaner to have
a "virtual/phobos" package, that is sensitive to the list of D
compilers as mentioned above.
One question I haven't finally answered yet is how to handle
libraries when there are multiple versions of D available.
For some programming languages this is solved by installing
libraries into <language_name>-<version>/ prefixes.
This certainly requires a more thoughtful dmd configuration
process. E.g. multiple dmd.conf for each installed version, to
point to the correct library directory. (A small patch to the
compiler sources during installation.)

Thoughs?

--=20
Marco
Nov 08 2013
next sibling parent reply "Chris Nicholson-Sauls" <ibisbasenji gmail.com> writes:
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.

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.

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.
Nov 08 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 09 Nov 2013 08:42:59 +0100
schrieb "Chris Nicholson-Sauls" <ibisbasenji 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
Nov 09 2013
prev sibling next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
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
Nov 08 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 09 Nov 2013 08:46:35 +0100
schrieb "Wyatt" <wyatt.epp gmail.com>:


 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.)


That sounds like an option. It might require some extensions
to dub though so we can have a library installed multiple
times for different compilers and D versions.


 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?)


There is a toolchain.eclass that creates the complete list of
IUSE for GCC, excluding 'd' for now. But without the front-end
source code in the source package it doesn't do anything
useful 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.


Yes, I had virtual/phobos in mind, but you guys a probably
right that it should be more general like virtual/dlang.


 - 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/*


I wouldn't separate Phobos out just yet. One package per D
implementation will do the job.


 - 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.


I asked Mr. Buclaw recently and he told me that is was still
an issue, at least when it comes to dmd.


 - 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...;)


Hehe, I can't really quantify it, but assumed that "dmd" is the
default for rdmd, dub, Mono-D and other tools. For many you
can override the compiler name, but it could still be helpful
to have /bin/dmd point to /bin/ldmd2-0.12.0 if LDC is the only
installed D compiler.


 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.


Ok, fair enough... We have D compilers that excel at different
things. A big selling point is the rapid turn around time of
code changes when compiling with dmd, but its optimizer is
lacking on modern CPUs. My choice is to setup my debug builds
to use dmd and the release builds to use gdc/ldc. Also
sometimes one compiler has a corner case with some code and it
helps to try another one till a bug fix is available. (So much
for the value of multiple compilers, on to multiple
versions...)
Some projects are still written in D1. And with the Phobos
library as an .so now, we have to see how we can keep multiple
versions of Phobos in case some application isn't updated for
half a year and happens to need that last Phobos version.


 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.


Some time you need to give me a who-is-who in Gentoo. Ok, just
what do you think is tolerable? gcc has quite a few versions,
but it doesn't really affect me. I have only 4.7.3-r1
installed. For D the story is different since the compiler and
standard library ship together and - from a packager's point of
view - it is all new every 2 to 5 months. If you have some D
programs installed that haven't been updated in a while you
have to keep old versions of phobos.so and other dependencies
around.


 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?


I have never looked at those in depth. Possibly yes, since
there is Python and GCC already.


 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.)


Hmm. This is actually my main motivation: Getting packages
like Derelict or GtkD working with both dmd for debug builds
and gdc for release builds without manual recompilation,
changing lib paths and library names, just by setting
D_COMPILERS="dmd gdc" in make.conf.


 -Wyatt


Thanks for your input. It is nice to talk about our options
here and to hear from few more D users on Gentoo that way.

-- 
Marco
Nov 09 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Some comments on general packaging topic.

On Saturday, 9 November 2013 at 00:38:16 UTC, Marco Leise wrote:

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


Not really true, it is straightforward to write an alternative 
druntime / stdlib substitution to use with existing compiler 
package.


 - Each new D point release brings a new, generally
   incompatible standard library.
 - 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).


Yes, ABI is the key issue that makes 3 major compiler ecosystems 
not interchangeable in any way. And it is not likely to be fixed 
any time soon.


 - Tools tend to expect that "dmd" is available as a command.


Actually I don't think this is true for newer ones. There are 
plenty that tend to either use `rdmd` or detect compiler present 
in the system.


 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).
 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".


I have been thinking about it when doing Arch packaging but 
discarded that approach as not KISS. All maintained applications 
support either latest compiler version or previous one. Rare 
cases when legacy version is needed are covered by dvm. In that 
sense pure bleeding edge model suits D realities most and only 
separation between dmd/ldc/gdc is needed.


 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.


And what if one wants to have all 3 simultaneously?


 ...


(rest is a bit too Gentoo-specific for me to make any reasonable 
input :))
Nov 09 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 09 Nov 2013 12:21:30 +0100
schrieb "Dicebot" <public dicebot.lv>:


 Some comments on general packaging topic.
 
 On Saturday, 9 November 2013 at 00:38:16 UTC, Marco Leise wrote:

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


 
 Not really true, it is straightforward to write an alternative 
 druntime / stdlib substitution to use with existing compiler 
 package.


Yeah, I was pointing at the lock-step upgrade nature of D
development. You can't really update one without the other
when it comes to every day package management.


 - Each new D point release brings a new, generally
   incompatible standard library.
 - 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).


 
 Yes, ABI is the key issue that makes 3 major compiler ecosystems 
 not interchangeable in any way. And it is not likely to be fixed 
 any time soon.
 

 - Tools tend to expect that "dmd" is available as a command.


 
 Actually I don't think this is true for newer ones. There are 
 plenty that tend to either use `rdmd` or detect compiler present 
 in the system.


Good, the only thing that might go wrong then is alternate
binary names or install locations.


 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).
 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".


 
 I have been thinking about it when doing Arch packaging but 
 discarded that approach as not KISS. All maintained applications 
 support either latest compiler version or previous one. Rare 
 cases when legacy version is needed are covered by dvm. In that 
 sense pure bleeding edge model suits D realities most and only 
 separation between dmd/ldc/gdc is needed.


Your experience is welcome! Does D1 have a place in that
model? And what does really happen when you work with e.g.
dmd-2.065 and found a D application in the tree that hasn't
been updated for a few weeks, so it still requires 2.064?
It would more or less mean that the whole D package system
would have to be updated in one go, when all packages are
updated to the latest D version, which can take a while.


 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.


 
 And what if one wants to have all 3 simultaneously?


You call them by their real names. :)

-- 
Marco
Nov 09 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 9 November 2013 at 13:23:33 UTC, Marco Leise wrote:

 Yeah, I was pointing at the lock-step upgrade nature of D
 development. You can't really update one without the other
 when it comes to every day package management.


True. This why I have them all in a single PKGBUILD (ebuild 
analog I guess) despite those looking separate in package manager.


 - Tools tend to expect that "dmd" is available as a command.


 
 Actually I don't think this is true for newer ones. There are 
 plenty that tend to either use `rdmd` or detect compiler 
 present in the system.


 Good, the only thing that might go wrong then is alternate
 binary names or install locations.


Well the idea is simple - whatever install locations are, 
packager provides default /etc/dmd.conf (ldc has similar conf 
file and gdc needs to be patched during build) that allow plain 
compiler invocations to "just work" without figuring out any 
actual path. I also have common base path for all D modules 
installed via `pacman` - "/usr/include/dlang/" which is in 
default `-I` list so that any library installed that way can be 
directly imported with no extra steps.


 Your experience is welcome! Does D1 have a place in that
 model?


AFAIK no one uses D1 but company I am working for :P


 And what does really happen when you work with e.g.
 dmd-2.065 and found a D application in the tree that hasn't
 been updated for a few weeks, so it still requires 2.064?


It is somewhat easier in Arch case as core repositories provide 
pre-compiled binary packages. So it does not really matter what 
compiler version is required for application if it is statically 
linked and is not a library on its own. For source-based packaged 
(AUR in Arch case) I'd send a pull request upstream :) Or mark it 
out-of-date and wait :)


 It would more or less mean that the whole D package system
 would have to be updated in one go, when all packages are
 updated to the latest D version, which can take a while.


It is pretty much what happens right now anyway as it is defined 
by nature of D versioning / releases and there is not much we can 
do about it :)


 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.


 
 And what if one wants to have all 3 simultaneously?


 You call them by their real names. :)


Well, "dmd" IS real name for dmd ;) In that sense that "dc" 
proposal makes much more sense.
Nov 10 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 10 Nov 2013 17:34:49 +0100
schrieb "Dicebot" <public dicebot.lv>:


 On Saturday, 9 November 2013 at 13:23:33 UTC, Marco Leise wrote:

 Yeah, I was pointing at the lock-step upgrade nature of D
 development. You can't really update one without the other
 when it comes to every day package management.


 
 True. This why I have them all in a single PKGBUILD (ebuild 
 analog I guess) despite those looking separate in package manager.


So a single PKGBUILD can advertise multiple items to install?
And when you later install more from the same package you just
run the PKGBUILD again and it reinstalls everything plus the
new options?


 - Tools tend to expect that "dmd" is available as a command.


 
 Actually I don't think this is true for newer ones. There are 
 plenty that tend to either use `rdmd` or detect compiler 
 present in the system.


 Good, the only thing that might go wrong then is alternate
 binary names or install locations.


 
 Well the idea is simple - whatever install locations are, 
 packager provides default /etc/dmd.conf (ldc has similar conf 
 file and gdc needs to be patched during build) that allow plain 
 compiler invocations to "just work" without figuring out any 
 actual path. I also have common base path for all D modules 
 installed via `pacman` - "/usr/include/dlang/" which is in 
 default `-I` list so that any library installed that way can be 
 directly imported with no extra steps.


+1 I use this prefix now, too. Each compiler also has a
subdirectory there.


 Your experience is welcome! Does D1 have a place in that
 model?


 
 AFAIK no one uses D1 but company I am working for :P


Yeah, and they hopefully don't use Gentoo... maybe it is time
to drop that version if it causes trouble. I'll try to have
at least an dmd-1.076 ebuild though. It is also a good test
for the whole multiple versions at once idea.


 And what does really happen when you work with e.g.
 dmd-2.065 and found a D application in the tree that hasn't
 been updated for a few weeks, so it still requires 2.064?


 
 It is somewhat easier in Arch case as core repositories provide 
 pre-compiled binary packages. So it does not really matter what 
 compiler version is required for application if it is statically 
 linked and is not a library on its own. For source-based packaged 
 (AUR in Arch case) I'd send a pull request upstream :) Or mark it 
 out-of-date and wait :)


Too many smilies, hehe. Well, it should be possible to have at
least one installable version of every package at any time.
Unless that package hasn't been updated for 10 months or so.
I don't want to run into a situation where you can't update
dmd because some application isn't updated or where I do
update dmd early and D programs can't be installed any longer
until they work with that latest version of D.


 It would more or less mean that the whole D package system
 would have to be updated in one go, when all packages are
 updated to the latest D version, which can take a while.


 
 It is pretty much what happens right now anyway as it is defined 
 by nature of D versioning / releases and there is not much we can 
 do about it :)


Well, we can keep "old copies" around till no one needs them
anymore. This is done for several other languages on Gentoo
and I have it working more or less for dmd now.


 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.


 
 And what if one wants to have all 3 simultaneously?


 You call them by their real names. :)


 
 Well, "dmd" IS real name for dmd ;) In that sense that "dc" 
 proposal makes much more sense.


Yep. I thought of it as an opt-in symlink in case dmd isn't
installed, so it could be emulated with gdmd or ldmd2.
/bin/dmd -> /usr/bin/dmd might also be an option for that...
Nah, I'll see what might be required by some tools.

-- 
Marco
Nov 10 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 10 November 2013 at 18:14:25 UTC, Marco Leise wrote:

 True. This why I have them all in a single PKGBUILD (ebuild 
 analog I guess) despite those looking separate in package 
 manager.


 So a single PKGBUILD can advertise multiple items to install?
 And when you later install more from the same package you just
 run the PKGBUILD again and it reinstalls everything plus the
 new options?


`PKGBUILD` in Arch Linux is simply a standard package building 
script, essentially a bash script with metadata. It is not a 
package on its own, in is used to create ones. It is convenient 
for maintenance to generate packages with a shared/related built 
process from a single PKGBUILD. This, for example, is the one for 
dmd stack : 
https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/dmd/PKGBUILD


 AFAIK no one uses D1 but company I am working for :P


 Yeah, and they hopefully don't use Gentoo... maybe it is time
 to drop that version if it causes trouble. I'll try to have
 at least an dmd-1.076 ebuild though. It is also a good test
 for the whole multiple versions at once idea.


Well, wish you good best luck with it :) I don't have any plans 
to support it in main repositories (actually, other TU's would 
have yelled at me even if I did as it is against Arch design :P)


 Too many smilies, hehe. Well, it should be possible to have at
 least one installable version of every package at any time.
 Unless that package hasn't been updated for 10 months or so.
 I don't want to run into a situation where you can't update
 dmd because some application isn't updated or where I do
 update dmd early and D programs can't be installed any longer
 until they work with that latest version of D.


If such package is a stand-alone application and does not seem to 
be maintained for some time it can be adjusted to use DVM to 
retrieve older version specifically to build itself. Not very 
convenient, but won't at least pollute the system with dozens of 
different compiler/phobos versions.
Nov 11 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 11 Nov 2013 14:22:34 +0100
schrieb "Dicebot" <public dicebot.lv>:


 `PKGBUILD` in Arch Linux is simply a standard package building 
 script, essentially a bash script with metadata. It is not a 
 package on its own, in is used to create ones. It is convenient 
 for maintenance to generate packages with a shared/related built 
 process from a single PKGBUILD. This, for example, is the one for 
 dmd stack : 
 https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/dmd/PKGBUILD


That looks very similar to an ebuild, with the major
difference that a PKGBUILD can define multiple packages and
an ebuild has USE flags I think.
 

 If such package is a stand-alone application and does not seem to 
 be maintained for some time it can be adjusted to use DVM to 
 retrieve older version specifically to build itself. Not very 
 convenient, but won't at least pollute the system with dozens of 
 different compiler/phobos versions.


We will see how bad it becomes, hehe. I hope that it will
mostly be the last to versions of a compiler and one older
version for the one program you happen to use that wasn't
updated for a while.

-- 
Marco
Nov 11 2013
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 11 November 2013 at 15:02:24 UTC, Marco Leise wrote:

 That looks very similar to an ebuild, with the major
 difference that a PKGBUILD can define multiple packages and
 an ebuild has USE flags I think.


I think it was inspired by ebuilds originally but got some local 
tweaks over years. Multiple package support is relatively recent 
addition, for example.
Nov 11 2013
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Sunday, 10 November 2013 at 18:14:25 UTC, Marco Leise wrote:

 Yeah, and they hopefully don't use Gentoo... maybe it is time
 to drop that version if it causes trouble. I'll try to have
 at least an dmd-1.076 ebuild though. It is also a good test
 for the whole multiple versions at once idea.


See, this is one of those times where it might have been nice if 
D2 had gone with dmd2 for its binary name.  Regardless, if you 
want to support D1, make it a slot, and mask it for all arches-- 
we don't exactly want to encourage its use at this point, IMO.  
This would be in the same general vein as dev-lang/dmd-bin (in 
the main tree, but terribly out-of-date).

Now, if it does get installed...an idea, though not a great one: 
If you look at mplayer and mplayer2, they both install roughly 
the same stuff to the same locations in their default 
distribution.  i.e. the binary is called mplayer in both the 
original and the fork.  So what happens in 
media-video/mplayer{,2} is mplayer2's stuff is renamed to match 
the $PN and there's an IUSE+=" symlink".  The symlink flag causes 
portage to install symlinks to the original mplayer stuff for 
transparent compatibility with various frontends and other stuff.


 Too many smilies, hehe. Well, it should be possible to have at
 least one installable version of every package at any time.
 Unless that package hasn't been updated for 10 months or so.
 I don't want to run into a situation where you can't update
 dmd because some application isn't updated or where I do
 update dmd early and D programs can't be installed any longer
 until they work with that latest version of D.


My understanding was we were fixing the soname versioning for 
phobos, so this should theoretically be caught by 
 preserved-rebuild or revdep-rebuild.  Was I incorrect?


 Yep. I thought of it as an opt-in symlink in case dmd isn't
 installed, so it could be emulated with gdmd or ldmd2.
 /bin/dmd -> /usr/bin/dmd might also be an option for that...
 Nah, I'll see what might be required by some tools.


I wonder at what point a d.eclass needs to be made to negotiate 
all of this; I'm really not sure.  On that note, you may want to 
watch out for degenerate cases like packages trying to select a 
preferred compiler, just in case.

-Wyatt
Nov 11 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 11 Nov 2013 15:43:11 +0100
schrieb "Wyatt" <wyatt.epp gmail.com>:


 On Sunday, 10 November 2013 at 18:14:25 UTC, Marco Leise wrote:

 Yeah, and they hopefully don't use Gentoo... maybe it is time
 to drop that version if it causes trouble. I'll try to have
 at least an dmd-1.076 ebuild though. It is also a good test
 for the whole multiple versions at once idea.


 See, this is one of those times where it might have been nice if 
 D2 had gone with dmd2 for its binary name.  Regardless, if you 
 want to support D1, make it a slot, and mask it for all arches-- 
 we don't exactly want to encourage its use at this point, IMO.  
 This would be in the same general vein as dev-lang/dmd-bin (in 
 the main tree, but terribly out-of-date).


The versions in the sunrise overlay are already slotted for
D1/D2. The D1 dmd is renamed to dmd1 there. While I'm not
planning to rename dmd to dmd2, I took the concept a level
further and slotted for _every_ D version (except patch
levels). At least the current version of D1 cannot become
outdated any more. It's paradox I know. ;)
 

 Now, if it does get installed...an idea, though not a great one: 
 If you look at mplayer and mplayer2, they both install roughly 
 the same stuff to the same locations in their default 
 distribution.  i.e. the binary is called mplayer in both the 
 original and the fork.  So what happens in 
 media-video/mplayer{,2} is mplayer2's stuff is renamed to match 
 the $PN and there's an IUSE+=" symlink".  The symlink flag causes 
 portage to install symlinks to the original mplayer stuff for 
 transparent compatibility with various frontends and other stuff.


Positive on that one. I install dmd1.076 and dmd2.064 and have
"eselect dlang set --dmd dmd1.076" set the dmd symlink to D1.


 Too many smilies, hehe. Well, it should be possible to have at
 least one installable version of every package at any time.
 Unless that package hasn't been updated for 10 months or so.
 I don't want to run into a situation where you can't update
 dmd because some application isn't updated or where I do
 update dmd early and D programs can't be installed any longer
 until they work with that latest version of D.


 My understanding was we were fixing the soname versioning for 
 phobos, so this should theoretically be caught by 
  preserved-rebuild or revdep-rebuild.  Was I incorrect?


Gentoo will keep the previous .so and the application
will continue to work, that is correct. But a clean state is
only reached when the application is rebuild for the new
version of the library using  preserved-rebuild and the
old .so is removed. And that's where Phobos might have a
changed API and the application wont compile any more.
It doesn't happen often I think, but there is also no
guarantee, no version number indicating a fixed API. And as
long as there are things like "shared" and allocators still to
iron out, I can live with that situation.


 Yep. I thought of it as an opt-in symlink in case dmd isn't
 installed, so it could be emulated with gdmd or ldmd2.
 /bin/dmd -> /usr/bin/dmd might also be an option for that...
 Nah, I'll see what might be required by some tools.


 
 I wonder at what point a d.eclass needs to be made to negotiate 
 all of this; I'm really not sure.


That was amongst the first things I had to write ^^. In a
separate overlay it doesn't really matter how many of them you
have. As long as it shortens ebuilds, I'm all for it. GCC
really works that way, too. The ebuild is surprisingly short.


 On that note, you may want to 
 watch out for degenerate cases like packages trying to select a 
 preferred compiler, just in case.


That's the fun of ebuild writing. Apart from the compiler I
also need to pass compiler and version down to any
dependencies. And I saw no other way but doing that through
USE flags. If that system works out, it will be annoying as
hell. You might already have installed GtkD for gdc, dmd and
ldc in 3 different language versions = 9x and then comes a new
dependency that requests a 10-th version so you have to wait
through 10 compiles of GtkD again.
The only way to independently install a package multiple times
is through slots, and I want to keep that option for what it is
intended. Multiple API versions of the library in question.


 -Wyatt


-- 
Marco
Nov 11 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-09 01:38, Marco Leise wrote:


 Next a symlink should be established to the current
 implementation of dmd, e.g.: /bin/dmd -> /bin/ldmd2.


Wouldn't it be better to have a symlink called "dc", similar to "cc" for 
the C compiler. But that would require the DMD release to included a 
"dc" symlink and have it available on all platforms. And also people 
start using that instead of directly using dmd.

On the other hand, it would be better to hide these things behind a tool 
like dub.

-- 
/Jacob Carlborg
Nov 09 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 09 Nov 2013 14:38:48 +0100
schrieb Jacob Carlborg <doob me.com>:


 On 2013-11-09 01:38, Marco Leise wrote:
 

 Next a symlink should be established to the current
 implementation of dmd, e.g.: /bin/dmd -> /bin/ldmd2.


 
 Wouldn't it be better to have a symlink called "dc", similar to "cc" for 
 the C compiler. But that would require the DMD release to included a 
 "dc" symlink and have it available on all platforms. And also people 
 start using that instead of directly using dmd.
 
 On the other hand, it would be better to hide these things behind a tool 
 like dub.


"dmd" and it's ilk (gdmd, ldmd2) have a known command line
syntax, "dc" doesn't. Symlinks are most useful when the
semantic stays the same. For example you can have "sh" be a
link to "bash" since bash recognizes being invoked as "sh" and
emulates it.
FWIW, DC as an environment variable across systems might be a
good thing. You can have that on Windows, too. Looking at the
file part of the path you could tell if it is ldc2, dmd, gdc
or rdmd...

-- 
Marco
Nov 09 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-09 14:52, Marco Leise wrote:


 "dmd" and it's ilk (gdmd, ldmd2) have a known command line
 syntax, "dc" doesn't. Symlinks are most useful when the
 semantic stays the same.


I might have been a bit unclear. I was thinking we had a symlink called 
"dc" that would point to dmd, gdmd or ldmd2. I don't like that you can 
invoke "dmd" and it will compile using GDC.

-- 
/Jacob Carlborg
Nov 10 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 November 2013 10:33, Jacob Carlborg <doob me.com> wrote:


 On 2013-11-09 14:52, Marco Leise wrote:

  "dmd" and it's ilk (gdmd, ldmd2) have a known command line

 syntax, "dc" doesn't. Symlinks are most useful when the
 semantic stays the same.


 I might have been a bit unclear. I was thinking we had a symlink called
 "dc" that would point to dmd, gdmd or ldmd2. I don't like that you can
 invoke "dmd" and it will compile using GDC.


It also makes no sense as both have wildly different compiler switch
names.  And for the switches that are the same, both interpret the switches
differently. ie:  '-I ./imports'  works for GDC but not DMD (for some
reason DMD doesn't like spaces between switches and switch arguments).


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-10 12:14, Iain Buclaw wrote:


 It also makes no sense as both have wildly different compiler switch
 names.  And for the switches that are the same, both interpret the
 switches differently. ie:  '-I ./imports'  works for GDC but not DMD
 (for some reason DMD doesn't like spaces between switches and switch
 arguments).


Right, it also depends on the flag. They're all quite inconsistent.

-- 
/Jacob Carlborg
Nov 10 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 10 Nov 2013 14:20:05 +0100
schrieb Jacob Carlborg <doob me.com>:


 On 2013-11-10 12:14, Iain Buclaw wrote:
 

 It also makes no sense as both have wildly different compiler switch
 names.  And for the switches that are the same, both interpret the
 switches differently. ie:  '-I ./imports'  works for GDC but not DMD
 (for some reason DMD doesn't like spaces between switches and switch
 arguments).


 
 Right, it also depends on the flag. They're all quite inconsistent.


Well, it doesn't hurt to add a "dc" symlink the way you
described it. As long as you use no spaces after -I and resort
to the basic stuff like adding -release -O -inline etc. it
should work.

I'm currently testing the parallel installation of
dmd-versions in Gentoo. After finding starting and stopping
work on a few experiments to figure out what is possible with
ebuilds, it was time for something simpler.

The biggest problem was the library path. I chose
/usr/lib{32,64}/dlang/<compiler>/ for now, where <compiler>
is "dmd-2.064". I don't know if I should add the .2 minor
version, too. But that's really a minor detail.
I solved that by replacing all occurrences of /etc/
with /etc/dlang/dmd-<version>/ in inifile.c and then putting
dmd.conf there with two sections for [Environment32] and
[Environment64], that point to the afore mentioned library
paths for 32-bit and 64-bit respectively.
I didn't know of these two sections until I looked at the dmd
source code. They also mean that I can remove
--no-warn-search-mismatch from DFLAGS, since 32-bit and
64-bit libraries are now clearly separated.

Next, I'll probably modify the dmd-2.063.2 ebuild in the same
fashion and look at the eselect python module to create a
counterpart for dlang.

-- 
Marco
Nov 10 2013
prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Does anyone have an idea how to go about GDC, especially once
the D front-end is integrated? Since GCC installations are
configured with gcc-config, there is a conflict for "eselect
dlang". To clarify, gcc-config copies the executables from

/usr/x86_64-pc-linux-gnu/gcc-bin/<version>/*
to
/usr/bin/*

I guess I should just stick to DMD and LDC for it then?
By the way "dc" is already the name of an arbitrary precision
expression evaluator and cannot be used for a symlink to the D
compiler of choice. :p

-- 
Marco
Nov 10 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote:

 Does anyone have an idea how to go about GDC, especially once
 the D front-end is integrated? Since GCC installations are
 configured with gcc-config, there is a conflict for "eselect
 dlang". To clarify, gcc-config copies the executables from

 /usr/x86_64-pc-linux-gnu/gcc-bin/<version>/*
 to
 /usr/bin/*

 I guess I should just stick to DMD and LDC for it then?
 By the way "dc" is already the name of an arbitrary precision
 expression evaluator and cannot be used for a symlink to the D
 compiler of choice. :p


I ignore gcc-config for GDC and explicitly maintain list of files 
to install and their target locations (it is very short). Not 
very gcc-ish but more allows more consistent deployment between 
different D compilers.
Nov 11 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 November 2013 13:14, Dicebot <public dicebot.lv> wrote:


 On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote:


 Does anyone have an idea how to go about GDC, especially once
 the D front-end is integrated? Since GCC installations are
 configured with gcc-config, there is a conflict for "eselect
 dlang". To clarify, gcc-config copies the executables from

 /usr/x86_64-pc-linux-gnu/gcc-bin/<version>/*
 to
 /usr/bin/*

 I guess I should just stick to DMD and LDC for it then?
 By the way "dc" is already the name of an arbitrary precision
 expression evaluator and cannot be used for a symlink to the D
 compiler of choice. :p


 I ignore gcc-config for GDC and explicitly maintain list of files to
 install and their target locations (it is very short). Not very gcc-ish but
 more allows more consistent deployment between different D compilers.



What do you define as being a "consistent deployment" ?


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 11 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 11 November 2013 at 13:45:10 UTC, Iain Buclaw wrote:

 What do you define as being a "consistent deployment" ?


Similar path patterns for binaries, standard libraries and import 
modules. Similar compilation defaults. Use of FE version as 
primary one (GDC is especially useless here as its native version 
is tied to GCC version and says nothing about supported language).
Nov 11 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 11 Nov 2013 15:08:22 +0100
schrieb "Dicebot" <public dicebot.lv>:


 On Monday, 11 November 2013 at 13:45:10 UTC, Iain Buclaw wrote:

 What do you define as being a "consistent deployment" ?


 
 Similar path patterns for binaries, standard libraries and import 
 modules. Similar compilation defaults. Use of FE version as 
 primary one (GDC is especially useless here as its native version 
 is tied to GCC version and says nothing about supported language).


That is a deficit. I'd like to make packages depend on a
version of the language, but that's not easy with LDC and GDC
at the moment. GDC is a mix of GCC version, D front-end
version, an ancient version number 0.30 and a Git commit
hash. :o)

Dicebot: I have decided that it makes most sense to not fight
GCC. D will eventually be an official GCC language and in the
Gentoo tree. That will be how you install GDC in the future.
We'll have to live with the binary, library and include
directories it creates.
I tried to have common directories between compilers, but
messing with the GCC installation is not on my agenda.
A good option might be to make the GDC ebuild behave exactly
like the GCC ebuild but block installation of GCC and GDC in
the same slot. That should be closest to what we will see in a
year (or so) when D is official in GCC. At that point the
separate GDC ebuild can be dropped.

As for detecting the language version there is always the
option to compile this and see:

module version.d;
paragma(msg, __VERSION__);

-- 
Marco
Nov 11 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 11 November 2013 at 15:54:11 UTC, Marco Leise wrote:

 D will eventually be an official GCC language and in the
 Gentoo tree. That will be how you install GDC in the future.
 We'll have to live with the binary, library and include
 directories it creates.


I actually fear that moment because the way GCC infrastructure 
works it is impossible to make language updates within single GCC 
stack version. So GDC users will likely just ignore obsolete 
version packaged with GCC and build their own. And we will get 
reports from frustrated newbies "I have installed gcc-d package 
from the repo and nothing compiles".

I like LLVM approach much better in that regard as it allows to 
define own versioning/release scheme.
Nov 11 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 November 2013 16:14, Dicebot <public dicebot.lv> wrote:


 On Monday, 11 November 2013 at 15:54:11 UTC, Marco Leise wrote:


 D will eventually be an official GCC language and in the
 Gentoo tree. That will be how you install GDC in the future.
 We'll have to live with the binary, library and include
 directories it creates.


 I actually fear that moment because the way GCC infrastructure works it is
 impossible to make language updates within single GCC stack version. So GDC
 users will likely just ignore obsolete version packaged with GCC and build
 their own. And we will get reports from frustrated newbies "I have
 installed gcc-d package from the repo and nothing compiles".

 I like LLVM approach much better in that regard as it allows to define own
 versioning/release scheme.


Nobody makes that complaint about gccgo.  So what you are describing is an
attitude unique to this community.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 11 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 11 November 2013 at 16:46:50 UTC, Iain Buclaw wrote:

 Nobody makes that complaint about gccgo.  So what you are 
 describing is an
 attitude unique to this community.


How do they handle language updates in gccgo?
Nov 11 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 November 2013 16:49, Dicebot <public dicebot.lv> wrote:


 On Monday, 11 November 2013 at 16:46:50 UTC, Iain Buclaw wrote:


 Nobody makes that complaint about gccgo.  So what you are describing is an
 attitude unique to this community.


 How do they handle language updates in gccgo?


There is current no 'release' per say for Go.  So the version of Go would
be whatever was the current stable as of the GCC release (or closing of
stage1 development).

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 11 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 11 November 2013 at 17:05:15 UTC, Iain Buclaw wrote:

 There is current no 'release' per say for Go.  So the version 
 of Go would
 be whatever was the current stable as of the GCC release (or 
 closing of
 stage1 development).


Well, you do realize it is completely unsuitable for D and will 
never work this way, don't you? :) And while I generally like to 
rant about lack of stable development process, GCC inverted 
approach seems much worse for anything that is not set in stone 
language covered by formalistic standard.
Nov 11 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 November 2013 17:42, Dicebot <public dicebot.lv> wrote:

 On Monday, 11 November 2013 at 17:05:15 UTC, Iain Buclaw wrote:

 There is current no 'release' per say for Go.  So the version of Go would
 be whatever was the current stable as of the GCC release (or closing of
 stage1 development).



 Well, you do realize it is completely unsuitable for D and will never


work this way, don't you? :) And while I generally like to rant about lack
of stable development process, GCC inverted approach seems much worse for
anything that is not set in stone language covered by formalistic standard.

It can work this way.  Perhaps with the realisation of a more stable
releases (eg: exercising that certain point releases get maintained for a
year).

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
On Monday, 11 November 2013 at 17:05:15 UTC, Iain Buclaw wrote:


 There is current no 'release' per say for Go.  So the version of Go would
 be whatever was the current stable as of the GCC release (or closing of
 stage1 development).


Well, you do realize it is completely unsuitable for D and will never work
this way, don't you? :) And while I generally like to rant about lack of
stable development process, GCC inverted approach seems much worse for
anything that is not set in stone language covered by formalistic standard.
Nov 11 2013
next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
GCC releases are as often as D releases now when I compare the
4.8.x series with the last D versions: 2 to 5 months.

-- 
Marco
Nov 11 2013
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 12 November 2013 at 06:37:03 UTC, Marco Leise wrote:

 GCC releases are as often as D releases now when I compare the
 4.8.x series with the last D versions: 2 to 5 months.


Yeah and Ubuntu still has 4.6 in main repos ;) It isn't as much 
GCC upstream issue as problem with being forced to sync with GCC 
suite updates in distributions (and thus being tied to stability 
requirements for C compiler updates in that distributions).
Nov 12 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 11 November 2013 at 21:31:50 UTC, Iain Buclaw wrote:

 It can work this way.  Perhaps with the realisation of a more 
 stable
 releases (eg: exercising that certain point releases get 
 maintained for a
 year).


I would have fully supported it but if it has not happened so far 
despite all the breaking change debates I can't see it happening 
in future just because of GCC.
Nov 12 2013
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote:

 Does anyone have an idea how to go about GDC, especially once
 the D front-end is integrated? Since GCC installations are
 configured with gcc-config, there is a conflict for "eselect
 dlang". To clarify, gcc-config copies the executables from

 /usr/x86_64-pc-linux-gnu/gcc-bin/<version>/*
 to
 /usr/bin/*

 I guess I should just stick to DMD and LDC for it then?
 By the way "dc" is already the name of an arbitrary precision
 expression evaluator and cannot be used for a symlink to the D
 compiler of choice. :p


On this point, it may be time to get on Freenode and hit up 
#gentoo-dev-help and see what they say.  Off the top of my head, 
EAPI 2 introduced USE deps, so you may be able to get away with 
specifying sys-devel/gcc[d] as fulfilling your virtual.

As far as eselect goes, I would use that only for fixing up the 
environment and the paths in sc.ini (and the primary compiler 
symlink, if you choose to go that route). I'm not familiar with 
the guts of it, but from what I've been told, an eselect module 
for gcc has been tried several times, but has always met 
unfortunate circumstances.

-Wyatt
Nov 11 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 11 Nov 2013 14:48:37 +0100
schrieb "Wyatt" <wyatt.epp gmail.com>:


 As far as eselect goes, I would use that only for fixing up the 
 environment and the paths in sc.ini (and the primary compiler 
 symlink, if you choose to go that route). I'm not familiar with 
 the guts of it, but from what I've been told, an eselect module 
 for gcc has been tried several times, but has always met 
 unfortunate circumstances.
 
 -Wyatt


Currently there is no environment to fix :). And that dmd.conf
file is now /etc/dlang/dmd2.064.conf.
It contains DFLAGS for 32-bit and 64-bit as well as version
specific include and library directories, making
--no-warn-search-mismatch obsolete in the general case.
The eselect only makes dmd, ldc, ldc2 and the man pages
available as symlinks for now. (Adapted from the Python
eselect module)

-- 
Marco
Nov 11 2013
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 9 Nov 2013 01:38:10 +0100
schrieb Marco Leise <Marco.Leise gmx.de>:

I abandoned my "gdc" ebuild and instead just copied
the original gcc ebuild and augmented it with a specific
checkout of gdc from Github. This means that you can freely
slot it with your existing gcc installation(s) or replace it
entirely. This lets us work with it as if D was already
officially included in gcc.
Currently there is gcc 4.8.1 with front-end version 2.063.2.
gcc 4.8.2 will have the 2.064.2 integration.
Libraries compiled with gdc will be placed in the existing
version specific gcc directory
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/
to avoid collisions with the same .so files compiled with
other D compilers.

-- 
Marco
Nov 14 2013