Am Sat, 09 Nov 2013 12:21:30 +0100 schrieb "Dicebot" <pub...@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
