digitalmars.D - Distributor's whishlist and questions for D
- Matthias Klumpp (74/74) Apr 20 2016 Hello!
- John Colvin (16/18) Apr 21 2016 These two can be answered at once. LDC and GDC share the same
- Johannes Pfau (19/30) Apr 21 2016 Once we have full ABI compatibility we need to make sure we can
- Johan Engelen (3/7) Apr 21 2016 Is performance of the outputted code a criterium? Or the number
- Matthias Klumpp (5/13) Apr 21 2016 The number of supported architectures is at least a criterium for
- Johannes Pfau (34/53) Apr 21 2016 /usr/include/d or /usr/include/dlang. I prefer /usr/include/d as
- Johannes Pfau (7/12) Apr 21 2016 We could probably also provide a small wrapper tool for this:
- Matthias Klumpp (33/79) Apr 21 2016 That doesn't seem to be the case for LDC on Debian... It installs
- Marco Leise (6/9) Apr 21 2016 See also:
- Marco Leise (8/17) Apr 21 2016 For gtkd 2.4.2 and 3.2.3 I have these directories:
- Johannes Pfau (21/66) Apr 21 2016 You're welcome :-)
- Kagamin (10/20) Apr 21 2016 Many D users are enthusiasts and push the compiler to its limits,
- Matthias Klumpp (40/53) Apr 21 2016 Asgen is super-boring code ;-) Mainly because the task it
- Kagamin (8/18) Apr 22 2016 One interesting possibility with D is that you can test what
- Kagamin (3/4) Apr 22 2016 Or not. If template constraint doesn't match, the error should be
- David Nadlinger (6/10) Apr 22 2016 Yes, this was indeed an LDC issue. We have our own
- Marco Leise (36/64) Apr 21 2016 Having been in a similar situation years ago, I can share my
- Dicebot (2/2) Apr 22 2016 FYI: I don't want to comment here for now because Debian packaging is
- Jacob Carlborg (22/68) Apr 23 2016 GDC does not completely implement the D2 specification. Not sure about
- Iain Buclaw via Digitalmars-d (3/14) Apr 24 2016 To be fair, DMD doesn't implement the D2 specification either.
- Jacob Carlborg (6/7) Apr 24 2016 I didn't say it did ;). There's also the question "what is the
Hello! Me bringing dub to Debian (and subsequently Ubuntu) has sparked quite some interest in getting more D applications shipped in Linux distributions. Since I think D is a great language, I would welcome that - in order to get more D code into distributions though, it would be awesome to sort out a few issues which currently (seem to) exist. So I created this list, first to raise a bit of awareness on the issues that I see, and second - because I am very new to D - to allow others to point out solutions to those problems, or explain a different view on why some things are (not) done in a certain way (yet). While I am thinking from a Debian point of view, quite some stuff is relevant for other distros as well. So, let's get started: This is an important question, because we would need to know whether we can expect D code to be compiled by any compiler, or whether there are tradeoffs that must be made. This question is asking manly how complete LDC and GDC are compared to each other, but also whether both are implementing the D2 specification completely. The question here is also, which compiler should be the default (which IMHO would be the most complete, most bug-free actively maintained one ^^). If one assumes that the D2 language specification is stable, and D compilers implement it completely, the question is why every compiler is shipping an own copy of Phobos. This is a major pain, since e.g. GDCs Phobos is behind what is documented on dlang.org, but also because the compilers sometimes accidentally use the "wrong" Phobos version (e.g. GDC trying to use the one of LDC), leading to breakage. Also, distributors hate code duplication, so deduplicating this would be awesome (druntime being compiler-specific makes sense to me, Phobos not so much...). It's not an essential thing, but would be quite nice... If I install a D library or source-only module as a distribution package, where should the sources be put? So far, I have seen: * /usr/include/d * /usr/include/dlang/ * /usr/include/d/(dmd|gdc|ldc) * /usr/share/dlang Having one canonical path would be awesome ;-) DUB currently only searches online for it's packages, but if we install them as distributor, we want dub to also look locally in some path where the packages can be found, and - if possible - use a prebuilt shared/static library. (reported as https://github.com/dlang/dub/issues/811 ) Ideally, dub would also have a "dub install" command, to install the binary, "headers (.di)"/sources and data into standard directories on Linux. (reported as https://github.com/dlang/dub/issues/811 ) ++++++ Aside from these things, there are also some other things which would be very useful: In distributions, we hate duplicating binary code copies. At time, D links everything statically, which means that when a bug is discovered in a library used by many other tools (worst case: the standard library), we will need to recompile all depending software. This is really annoying for the security team, while not being as bad as having actual duplicate source-code copies which need to be patched individually. Simple: Compile your library with GDC, have it used by code compiled with LDC. Otherwise, shared libraries would be of very limited use. Cheers, Matthias
Apr 20 2016
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:These two can be answered at once. LDC and GDC share the same frontend code as DMD, but not the glue layer and backend (don't worry, it's only the DMD backend that has the more restrictive licence). Language and library development happens in DMD and with regard to DMD's current capabilities. Changes to DMD and druntime often require effort to port to LDC and GDC, due to the different backends. So an LDC or GDC release is complete w.r.t. a given past DMD version, but new features may have been added in more recent DMDs. The constraints on shipping a shared phobos between them: ABI compatibility: we don't have it, even across compiler versions It would hold back phobos development (e.g. "you can't do that, because GDC doesn't support it yet") You would still need to ship a separate runtime for each compiler, so you don't really gain anything.
Apr 21 2016
On Thursday, 21 April 2016 at 08:30:59 UTC, John Colvin wrote:On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:Once we have full ABI compatibility we need to make sure we can work with a shared druntime: If an application compiled with compiler A(requiring runtime A) should be able to link with a shared library compiled by compiler B (requiring runtime B) both 'modules' need to use the same runtime => runtime A==B. This is because we can't have two GCs running concurrently (and there's some more low-level stuff). What we need is a defined ABI for druntime. Then one druntime implementation is installed system wide. The implementation can differ (e.g. GDC might use GCC builtins) but the ABI needs to be fixed to make sure every compiler can use the 'system' druntime. Think of libc or libc++ for example: You can't reliably link modules from compilers using different libcs (or you end up with GC proxies and similar hacks). Compiler specific extensions (gcc.builtins, etc) then must be moved to extra libraries (libgdc) (only if they affect the ABI though. gcc.builtins is actually a bad example as it doesn't contain non-extern functions).The constraints on shipping a shared phobos between them: ABI compatibility: we don't have it, even across compiler versions It would hold back phobos development (e.g. "you can't do that, because GDC doesn't support it yet") You would still need to ship a separate runtime for each compiler, so you don't really gain anything.
Apr 21 2016
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:The question here is also, which compiler should be the default (which IMHO would be the most complete, most bug-free actively maintained one ^^).Is performance of the outputted code a criterium? Or the number of supported architectures?
Apr 21 2016
On Thursday, 21 April 2016 at 09:07:57 UTC, Johan Engelen wrote:On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:The number of supported architectures is at least a criterium for Debian (speed is also important, obviously ^^) - for arch support, one could set a different compiler on different architectures though...The question here is also, which compiler should be the default (which IMHO would be the most complete, most bug-free actively maintained one ^^).Is performance of the outputted code a criterium? Or the number of supported architectures?
Apr 21 2016
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:If I install a D library or source-only module as a distribution package, where should the sources be put? So far, I have seen: * /usr/include/d * /usr/include/dlang/ * /usr/include/d/(dmd|gdc|ldc) * /usr/share/dlang Having one canonical path would be awesome ;-)/usr/include/d or /usr/include/dlang. I prefer /usr/include/d as it's shorter, but the important point is that we need to decide on a common standard. You currently can't install druntime or phobos headers in this directory, as each compiler will have slightly modified versions and then you end up with /usr/include/d/(dmd|gdc|ldc). But all other library headers should be shareable between compilers and can be placed in /usr/include/d. (This might even work for phobos, I don't think we have many compiler specific changes there. But then you need to use the same frontend version for all compilers.) You can only install headers for one library version with this approach! A versioned approach is nicer /usr/include/d/libfoo/1.0.0 but requires explicit compiler support and it's unlikely this will happen (or explicit dub support and you compile everything through dub).What does FHS recommend in this case? If you only keep headers/sources you could install into /usr/include. Otherwise you probably need /var/cache or /var/lib or somehting like that. If you split packages you could use the standard /usr/lib* folders but then you need to keep versioned subdirectories to support installing multiple versions.Ideally, dub would also have a "dub install" command, to install the binary, "headers (.di)"/sources and data into standard directories on Linux. (reported as https://github.com/dlang/dub/issues/811 )See above. The main question is: Do you want to have a C style install of one version of a library and have gdc find the includes and library when running gdc main.a -libfoo or do you want dub-style support for multiple library versions which means you need to compile everything through dub. I'd love to have some extended compiler support (so you could simply do gdc -use=libfoo:1.0.0 and this would pick up the correct headers and linker flags). But as some DMD maintainers are opposed to this idea it won't happen. You'll probably always need dub for a 'nice' user interface.++++++ Aside from these things, there are also some other things which would be very useful:This is mainly a GDC issue. DMD and LDC support shared libs, although I don't think these libraries are ABI compatible.
Apr 21 2016
On Thursday, 21 April 2016 at 11:49:13 UTC, Johannes Pfau wrote:I'd love to have some extended compiler support (so you could simply do gdc -use=libfoo:1.0.0 and this would pick up the correct headers and linker flags). But as some DMD maintainers are opposed to this idea it won't happen. You'll probably always need dub for a 'nice' user interface.We could probably also provide a small wrapper tool for this: pkgdc gdc -use=libfoo:1.0.0 -other -gdc-args pkgdc dmd -use=libfoo:1.0.0 -other -dmd-args looks up package flags and calls the real compiler with appropriate args. We'd need to define standard for this to be really useful though.
Apr 21 2016
Hi, and thanks for your detailed explanations! On Thursday, 21 April 2016 at 11:49:13 UTC, Johannes Pfau wrote:On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:That doesn't seem to be the case for LDC on Debian... It installs Phobos into /usr/include/d/std, which makes GDC go crazy as soon as LDC is installed too. I suspect this is a packaging bug, if so, I'll report a bug against LDC.[...]You currently can't install druntime or phobos headers in this directory, as each compiler will have slightly modified versions and then you end up with /usr/include/d/(dmd|gdc|ldc).But all other library headers should be shareable between compilers and can be placed in /usr/include/d. (This might even work for phobos, I don't think we have many compiler specific changes there. But then you need to use the same frontend version for all compilers.)This is probably a very naive question, but: Isn't the D specification finished? If the language is done, why would there be a dependence of Phobos on a specific compiler? Or is this because the new code in Phobos might expose bugs in the compiler itself, which causes these incompatibilities?You can only install headers for one library version with this approach! A versioned approach is nicer /usr/include/d/libfoo/1.0.0 but requires explicit compiler support and it's unlikely this will happen (or explicit dub support and you compile everything through dub).Would be nice, but since we - most of the time - only allow one version of a specific software package to be present in distributions, it isn't a huge issue.By the FHS, /usr/include/d should be okay for headers (well, the spec explicitly says C programming language headers, but well.... :P).What does FHS recommend in this case? If you only keep headers/sources you could install into /usr/include.Otherwise you probably need /var/cache or /var/lib or somehting like that./var/cache and /var/lib are forbidden for distributors, since they contain state information which shouldn't be touched (as always, there are exceptions...). If the dub packages contain architecture-independent stuff only, they need to go to /usr/share/dlang or /usr/include/d, and the shared or static library must go to /usr/lib/<triplet>/.If you split packages you could use the standard /usr/lib* folders but then you need to keep versioned subdirectories to support installing multiple versions.Multiple versions would be a rare event, since no distro package management system allows that (excluding Nix here, which is kind of special). Installing arbitrary arch-specific content into a subdirectory in /usr/lib is fine too, but I doubt that will be necessary...For plain gdc/ldc, I'd say: yesIdeally, dub would also have a "dub install" command, to install the binary, "headers (.di)"/sources and data into standard directories on Linux. (reported as https://github.com/dlang/dub/issues/811 )See above. The main question is: Do you want to have a C style install of one version of a library and have gdc find the includes and library when running gdc main.a -libfooor do you want dub-style support for multiple library versions which means you need to compile everything through dub.For stuff using dub, I'd say yes to that too ;-)I'd love to have some extended compiler support (so you could simply do gdc -use=libfoo:1.0.0 and this would pick up the correct headers and linker flags). But as some DMD maintainers are opposed to this idea it won't happen. You'll probably always need dub for a 'nice' user interface.Sounds more and more like LDC is - at time - the better choice over GDC...++++++ Aside from these things, there are also some other things which would be very useful:This is mainly a GDC issue. DMD and LDC support shared libs, although I don't think these libraries are ABI compatible.
Apr 21 2016
Am Thu, 21 Apr 2016 15:34:35 +0000 schrieb Matthias Klumpp <matthias tenstral.net>:That doesn't seem to be the case for LDC on Debian... It installs Phobos into /usr/include/d/std, which makes GDC go crazy as soon as LDC is installed too.See also: http://forum.dlang.org/post/mailman.1433.1460903305.26339.digitalmars-d-ldc puremagic.com -- Marco
Apr 21 2016
For gtkd 2.4.2 and 3.2.3 I have these directories: /usr/include/dlang/gtkd-2 /usr/include/dlang/gtkd-3 It makes sense, since Gtk2 can be installed in parallel with Gtk3 and the major version suffix ensures both packages wont overwrite each other's imports. -- MarcoYou can only install headers for one library version with this approach! A versioned approach is nicer /usr/include/d/libfoo/1.0.0 but requires explicit compiler support and it's unlikely this will happen (or explicit dub support and you compile everything through dub).Would be nice, but since we - most of the time - only allow one version of a specific software package to be present in distributions, it isn't a huge issue.
Apr 21 2016
Am Thu, 21 Apr 2016 15:34:35 +0000 schrieb Matthias Klumpp <matthias tenstral.net>:Hi, and thanks for your detailed explanations!You're welcome :-)On Thursday, 21 April 2016 at 11:49:13 UTC, Johannes Pfau wrote:IIRC GDC makes sure to install in some lib/gcc directory to avoid such problems. But it's possible ldc defaults to the include directory. As an example, Arch Linux configures all compilers to use /usr/include/dlang&(ldc|gdc|dmd): https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/ldc#n37 https://projects.archlinux.org/svntogit/community.git/tree/trunk/folders.diff?h=packages/gdc https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dmd#n54On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:That doesn't seem to be the case for LDC on Debian... It installs Phobos into /usr/include/d/std, which makes GDC go crazy as soon as LDC is installed too. I suspect this is a packaging bug, if so, I'll report a bug against LDC.[...]You currently can't install druntime or phobos headers in this directory, as each compiler will have slightly modified versions and then you end up with /usr/include/d/(dmd|gdc|ldc).We only introduce backwards compatible changes, but it's still possible that a new feature will be used in a new phobos version. Most of the time it's some obscure template bug fix which will require a new frontend version. And phobos is often one of the first libraries to use bug fixes or new compiler features.But all other library headers should be shareable between compilers and can be placed in /usr/include/d. (This might even work for phobos, I don't think we have many compiler specific changes there. But then you need to use the same frontend version for all compilers.)This is probably a very naive question, but: Isn't the D specification finished? If the language is done, why would there be a dependence of Phobos on a specific compiler? Or is this because the new code in Phobos might expose bugs in the compiler itself, which causes these incompatibilities?[...]Where do ruby / python package managers install their packages? I guess they're special as they use arch-independent sources? Anyway, for a one-version system wide install standard /usr/include/d and /usr/lib is probably best. I don't know a reasonable location for a dub 'repository' though.See above. The main question is: Do you want to have a C style install of one version of a library and have gdc find the includes and library when running gdc main.a -libfooFor plain gdc/ldc, I'd say: yesor do you want dub-style support for multiple library versions which means you need to compile everything through dub.For stuff using dub, I'd say yes to that too ;-)GDC is indeed lagging behind a little bit. We're working on it ;-)Sounds more and more like LDC is - at time - the better choice over GDC...This is mainly a GDC issue. DMD and LDC support shared libs, although I don't think these libraries are ABI compatible.
Apr 21 2016
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:This is an important question, because we would need to know whether we can expect D code to be compiled by any compiler, or whether there are tradeoffs that must be made. This question is asking manly how complete LDC and GDC are compared to each other, but also whether both are implementing the D2 specification completely. The question here is also, which compiler should be the default (which IMHO would be the most complete, most bug-free actively maintained one ^^).Many D users are enthusiasts and push the compiler to its limits, they are usually stuck with DMD (even DMD HEAD sometimes) as it provides the latest fixes. It depends on the coding style, AppStream generator is an example of old good plain business logic one is unlikely to need recent frontend for, but for people writing black magic code a couple of versions lag of free compilers behind DMD is usually a blocker, but whoever uses the free compilers already considers them complete enough for their tasks. Currently LDC looks like the most actively maintained one.
Apr 21 2016
On Thursday, 21 April 2016 at 11:58:23 UTC, Kagamin wrote:On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:Asgen is super-boring code ;-) Mainly because the task it performs can be represented without using much black magic. But still, in order to make it work, I needed to embed a copy of std.concurrency.Generator in my code, because GDCs Phobos didn't contain that thing yet (and it's *so* useful!). Basically, the huge differences in the standard versions is what annoyed me the most in D, since it also means you can't trust the documentation much, depending on the compiler you use. For someone new to D, this is annoying. LDC also fails to compile asgen: ``` /usr/include/d/std/parallelism.d-mixin-3811(3837): Error: template core.atomic.atomicOp cannot deduce function from argument types !("+=")(shared(ulong), int), candidates are: /usr/include/d/core/atomic.d(178): core.atomic.atomicOp(string op, T, V1)(ref shared T val, V1 mod) if (__traits(compiles, mixin("val" ~ op ~ "mod"))) /usr/include/d/std/parallelism.d-mixin-3811(3837): Error: template core.atomic.atomicOp cannot deduce function from argument types !("+=")(shared(ulong), int), candidates are: /usr/include/d/core/atomic.d(178): core.atomic.atomicOp(string op, T, V1)(ref shared T val, V1 mod) if (__traits(compiles, mixin("val" ~ op ~ "mod"))) /usr/include/d/std/parallelism.d-mixin-3823(3849): Error: template core.atomic.atomicOp cannot deduce function from argument types !("+=")(shared(ulong), int), candidates are: /usr/include/d/core/atomic.d(178): core.atomic.atomicOp(string op, T, V1)(ref shared T val, V1 mod) if (__traits(compiles, mixin("val" ~ op ~ "mod"))) /usr/include/d/std/parallelism.d(3344): Error: template instance std.parallelism.ParallelForeach!(Package[]) error instantiating source/engine.d(90): instantiated from here: parallel!(Package[]) ``` while GDC compiles the code flawlessly (LDC previously even crashed, but that was with the beta version). I will investigate why this happens now, but it's basically these small things which make working with D less fun, at least when you want to use a system without proprietary components.[...]Many D users are enthusiasts and push the compiler to its limits, they are usually stuck with DMD (even DMD HEAD sometimes) as it provides the latest fixes. It depends on the coding style, AppStream generator is an example of old good plain business logic one is unlikely to need recent frontend for, but for people writing black magic code a couple of versions lag of free compilers behind DMD is usually a blocker, but whoever uses the free compilers already considers them complete enough for their tasks. Currently LDC looks like the most actively maintained one.
Apr 21 2016
On Thursday, 21 April 2016 at 15:41:17 UTC, Matthias Klumpp wrote:Asgen is super-boring code ;-) Mainly because the task it performs can be represented without using much black magic.One interesting possibility with D is that you can test what performance impact boundschecking has on your code with just a compiler switch. Is asgen performance sensitive?LDC also fails to compile asgen: ``` /usr/include/d/std/parallelism.d-mixin-3811(3837): Error: template core.atomic.atomicOp cannot deduce function from argument types !("+=")(shared(ulong), int), candidates are: /usr/include/d/core/atomic.d(178): core.atomic.atomicOp(string op, T, V1)(ref shared T val, V1 mod) if (__traits(compiles, mixin("val" ~ op ~ "mod")))RMW operations on shared data are deprecated. The template filter on atomicOp is a little different: https://dlang.org/phobos/core_atomic.html#.atomicOp Looks like an LDC bug.
Apr 22 2016
On Friday, 22 April 2016 at 09:18:48 UTC, Kagamin wrote:Looks like an LDC bug.Or not. If template constraint doesn't match, the error should be "template instance does not match template declaration".
Apr 22 2016
On Friday, 22 April 2016 at 09:18:48 UTC, Kagamin wrote:RMW operations on shared data are deprecated. The template filter on atomicOp is a little different: https://dlang.org/phobos/core_atomic.html#.atomicOp Looks like an LDC bug.Yes, this was indeed an LDC issue. We have our own implementation, and apparently missed that the template constraint on the DMD version was updated: https://github.com/ldc-developers/ldc/pull/1456 — David
Apr 22 2016
Am Thu, 21 Apr 2016 01:01:01 +0000 schrieb Matthias Klumpp <matthias tenstral.net>:Hello! Me bringing dub to Debian (and subsequently Ubuntu) has sparked quite some interest in getting more D applications shipped in Linux distributions.Having been in a similar situation years ago, I can share my experience with packaging Dlang libraries and programs.If one assumes that the D2 language specification is stable, and D compilers implement it completely, the question is why every compiler is shipping an own copy of Phobos. This is a major pain, since e.g. GDCs Phobos is behind what is documented on dlang.org, but also because the compilers sometimes accidentally use the "wrong" Phobos version (e.g. GDC trying to use the one of LDC), leading to breakage. Also, distributors hate code duplication, so deduplicating this would be awesome (druntime being compiler-specific makes sense to me, Phobos not so much...). It's not an essential thing, but would be quite nice...The compiler devs would need to explain the coupling of druntime and Phobos. What I know is that Dlang's ABI and Phobos' API are still changing. There are at this very moment talks about changing the function name mangling, a deprecation of broken visibility rules and the shared keyword will need a rewrite at some point in the future. In practice you have a different Phobos per compiler and language release. I currently have 9 versions of Phobos installed, most of them in 4 flavors: 32-bit/64-bit, shared and static.If I install a D library or source-only module as a distribution package, where should the sources be put? So far, I have seen: * /usr/include/d * /usr/include/dlang/ * /usr/include/d/(dmd|gdc|ldc) * /usr/share/dlang Having one canonical path would be awesome ;-)As explained Phobos is installed in multiple versions, so I mostly used the compilers' defaults. For third party libraries I had the same question and figured the best would be a poll. Since November 2013 over 100 votes were cast with ~2/3 preferring /usr/include/dlang/ over /usr/include/d/: http://www.easypolls.net/poll.html?p=52828149e4b06cfb69b97527 This is today the de-facto path on Arch and Gentoo at least.For packaging purposes I avoided dub in the past as too much of a black box, for the flexibility usually expected on Gentoo. Many packages ship with make files that integrate better with the system's package manager.+1. For dmd, I changed the default in dmd.conf to link with the shared Phobos. It's been working pretty well since around 2.065 or so. I also install packages like gtkd with .soI agree with you, but let me add that you need multiple Phobos versions installed in parallel in some cases. You may have an app that depends on a library that doesn't compile with the latest dmd/Phobos. IIRC gtkd for Gtk2 doesn't work on dmd-2.071 any more. -- Marco
Apr 21 2016
FYI: I don't want to comment here for now because Debian packaging is very different from Arch packaging but I am keeping my eyes on the thread :)
Apr 22 2016
On 2016-04-21 03:01, Matthias Klumpp wrote:This is an important question, because we would need to know whether we can expect D code to be compiled by any compiler, or whether there are tradeoffs that must be made. This question is asking manly how complete LDC and GDC are compared to each other, but also whether both are implementing the D2 specification completely.GDC does not completely implement the D2 specification. Not sure about LDC. GDC is several versions behind DMD. LDC are much closer to DMD these days. Perhaps only one version behind.The question here is also, which compiler should be the default (which IMHO would be the most complete, most bug-free actively maintained one ^^).I would suggest LDC because it more up to date with DMD.If one assumes that the D2 language specification is stable, and D compilers implement it completely,No. It tries to avoid breaking changes on purpose (there will always be bug fixes that breaks code and introduction of new bugs). But new additions are added almost for each new release.the question is why every compiler is shipping an own copy of Phobos.I'm guessing because Phobos might depend on bugs that was fixed in the latest release and new features are used early. A language feature might also have been added because it was needed for a larger Phobos addition.If I install a D library or source-only module as a distribution package, where should the sources be put? So far, I have seen: * /usr/include/d * /usr/include/dlang/ * /usr/include/d/(dmd|gdc|ldc) * /usr/share/dlang Having one canonical path would be awesome ;-)Personally I would say that all libraries should be used through Dub, making this a non issue.DUB currently only searches online for it's packages, but if we install them as distributor, we want dub to also look locally in some path where the packages can be found, and - if possible - use a prebuilt shared/static library. (reported as https://github.com/dlang/dub/issues/811 ) Ideally, dub would also have a "dub install" command, to install the binary, "headers (.di)"/sources and data into standard directories on Linux. (reported as https://github.com/dlang/dub/issues/811 )For libraries, as I above, use Dub. For tools/applications they can hopefully be packaged completely separately.++++++ Aside from these things, there are also some other things which would be very useful: In distributions, we hate duplicating binary code copies. At time, D links everything statically, which means that when a bug is discovered in a library used by many other tools (worst case: the standard library), we will need to recompile all depending software. This is really annoying for the security team, while not being as bad as having actual duplicate source-code copies which need to be patched individually.Most D applications are linked statically because dynamic libraries have not been supported at all until recently. In addition to that most computers will not have the D runtime and standard library installed.Simple: Compile your library with GDC, have it used by code compiled with LDC. Otherwise, shared libraries would be of very limited use.Yeah, that would be nice :). Currently there's no guarantee about ABI compatibility at all. -- /Jacob Carlborg
Apr 23 2016
On 23 April 2016 at 21:35, Jacob Carlborg via Digitalmars-d <digitalmars-d puremagic.com> wrote:On 2016-04-21 03:01, Matthias Klumpp wrote:To be fair, DMD doesn't implement the D2 specification either.This is an important question, because we would need to know whether we can expect D code to be compiled by any compiler, or whether there are tradeoffs that must be made. This question is asking manly how complete LDC and GDC are compared to each other, but also whether both are implementing the D2 specification completely.GDC does not completely implement the D2 specification. Not sure about LDC. GDC is several versions behind DMD. LDC are much closer to DMD these days. Perhaps only one version behind.
Apr 24 2016
On 2016-04-24 15:20, Iain Buclaw via Digitalmars-d wrote:To be fair, DMD doesn't implement the D2 specification either.I didn't say it did ;). There's also the question "what is the specification?". DMD, http://dlang.org/spec/spec.html, TDPL or a combination of all of them. -- /Jacob Carlborg
Apr 24 2016