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:


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





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:





 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:


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





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



 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:




 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.





 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:


 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.



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





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:



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



 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