On 2016-04-21 03:01, Matthias Klumpp wrote:
## How complete are the free compilers? 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.
## Why is every D compiler shipping an own version of Phobos? 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.
## Where should D source-code / D interfaces be put? 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: Where should dub modules be installed? 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 ) ## dub: How to install modules? 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: ## Shared library support in all compilers 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.
## Stable ABI among compilers 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
