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