2015-06-01 20:03 GMT+02:00 Johannes Pfau via Digitalmars-d < digitalmars-d@puremagic.com>:
> > The main problem is we don't have ABI compatibility. This means we can't > share the libraries between compilers. So we could make 'import foo' > work but linking with -lfoo without manually adjusting linker paths is > not possible. > > There are some solutions, all have drawbacks: > * Have compiler specific directories for libraries > (/usr/lib/gdc/libvibed.a, /usr/lib/dmd/libvibed.a). Only works for > static libraries. Can only have one version of a library installed > * have per-library directories. I guess dub uses this. Can have > multiple versions of the same library. Drawback: compiler can't know > the correct library path.[1] > * Shared libraries should be installed in a common location (/usr/lib) > anyway. This is only possible if we have ABI compatibility[2]. > Library versioning is limited to the standard C/C++ like versioning. > > I guess the main reason why we can't have a C/C++ like out of the box > experience is ABI compatibility. There'll always be some quirks as long > as we don't fix this. > > Glad to see that post ! 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. 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.