www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Distributor's whishlist and questions for D

reply Matthias Klumpp <matthias tenstral.net> writes:
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:

## 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.
The question here is also, which compiler should be the default 
(which IMHO would be the most complete, most bug-free actively 
maintained one ^^).

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

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

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

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

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

Cheers,
     Matthias
Apr 20 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:
 ## How complete are the free compilers?
 ## Why is every D compiler shipping an own version of Phobos?
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
parent Johannes Pfau <nospam example.com> writes:
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:
 ## How complete are the free compilers?
 ## Why is every D compiler shipping an own version of Phobos?
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.
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).
Apr 21 2016
prev sibling next sibling parent reply Johan Engelen <j j.nl> writes:
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
parent Matthias Klumpp <matthias tenstral.net> writes:
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 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?
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...
Apr 21 2016
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:
 ## 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 ;-)
/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).
 ## dub: Where should dub modules be installed?
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.
 ## 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 )
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:

 ## Shared library support in all compilers
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
next sibling parent Johannes Pfau <nospam example.com> writes:
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
prev sibling parent reply Matthias Klumpp <matthias tenstral.net> writes:
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:
 [...]
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).
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.
 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.
 ## dub: Where should dub modules be installed?
What does FHS recommend in this case? If you only keep headers/sources you could install into /usr/include.
By the FHS, /usr/include/d should be okay for headers (well, the spec explicitly says C programming language headers, but well.... :P).
 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...
 ## 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 )
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
For plain gdc/ldc, I'd say: yes
 or 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.

 ++++++
 Aside from these things, there are also some other things 
 which would be very useful:

 ## Shared library support in all compilers
This is mainly a GDC issue. DMD and LDC support shared libs, although I don't think these libraries are ABI compatible.
Sounds more and more like LDC is - at time - the better choice over GDC...
Apr 21 2016
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
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
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
 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.
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. -- Marco
Apr 21 2016
prev sibling parent Johannes Pfau <nospam example.com> writes:
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:
 On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp 
 wrote:  
 [...]  
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).
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.
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#n54
 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?
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.
 [...]
 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  
For plain gdc/ldc, I'd say: yes
 or 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 ;-)
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.
 ## Shared library support in all compilers  
This is mainly a GDC issue. DMD and LDC support shared libs, although I don't think these libraries are ABI compatible.
Sounds more and more like LDC is - at time - the better choice over GDC...
GDC is indeed lagging behind a little bit. We're working on it ;-)
Apr 21 2016
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Thursday, 21 April 2016 at 01:01:01 UTC, 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.
 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
parent reply Matthias Klumpp <matthias tenstral.net> writes:
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:
 [...]
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.
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.
Apr 21 2016
parent reply Kagamin <spam here.lot> writes:
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
next sibling parent Kagamin <spam here.lot> writes:
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
prev sibling parent David Nadlinger <code klickverbot.at> writes:
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
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
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.
 ## 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, 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.
 ## 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 ;-)
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.
 ## dub: Where should dub modules be installed?
 ## dub: How to install modules?
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.
 ## Shared library support in all compilers
+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 .so
 ## Stable ABI among compilers
I 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
prev sibling next sibling parent Dicebot <public dicebot.lv> writes:
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
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Apr 23 2016
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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:

 ## 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.
To be fair, DMD doesn't implement the D2 specification either.
Apr 24 2016
parent Jacob Carlborg <doob me.com> writes:
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