<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-06-01 20:03 GMT+02:00 Johannes Pfau via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The main problem is we don't have ABI compatibility. This means we can't<br>
share the libraries between compilers. So we could make 'import foo'<br>
work but linking with -lfoo without manually adjusting linker paths is<br>
not possible.<br>
<br>
There are some solutions, all have drawbacks:<br>
* Have compiler specific directories for libraries<br>
  (/usr/lib/gdc/libvibed.a, /usr/lib/dmd/libvibed.a). Only works for<br>
  static libraries. Can only have one version of a library installed<br>
* have per-library directories. I guess dub uses this. Can have<br>
  multiple versions of the same library. Drawback: compiler can't know<br>
  the correct library path.[1]<br>
* Shared libraries should be installed in a common location (/usr/lib)<br>
  anyway. This is only possible if we have ABI compatibility[2].<br>
  Library versioning is limited to the standard C/C++ like versioning.<br>
<br>
I guess the main reason why we can't have a C/C++ like out of the box<br>
experience is ABI compatibility. There'll always be some quirks as long<br>
as we don't fix this.<br><br></blockquote><div><br></div><div>Glad to see that post !</div><div><br></div><div>But in addition of the ABI compatibility between compilers, we would need to have ABI compatibility between releases of the same major version if we were to walk the C[++] route, and we do not want that, for various reason, the most obvious one being that you won't be able to add an attribute like @nogc / nothrow to a free function without doing a major release.</div><div><br></div><div>There is good thing about C way of doing thing, but there is also some bad. For example, you can't have multiple versions of the same library installed - you don't need it -, but D definitely needs that. That also leads to major releases ending up in a different package - think qt4 / qt5 -. So, while C use SemVer for ABI compatibility, we should use SemVer for source compatibility, or we'll end up with an unmanageable mess.<br></div></div></div></div>