On Thursday, 14 April 2016 at 17:46:55 UTC, Johannes Pfau wrote:
[...]
(1) Interface files
We have .di interface files as a replacement for C/C++ headers
(although the .di extension is only a convention, you can also
use the .d extension). These files do not contain function
bodies, but they still need the complete source code for
templates. The compilers can generate interface files from
normal source code.
https://dlang.org/dmd-linux.html#interface-files
Looks like a pretty good choice for handling the
interface-with-library issue.
OSS projects do not use interface files though: It prevents
inlining of functions and there's no real benefit for OSS
projects. Interface files are (theoretically) useful for closed
source libraries if you don't want to ship the source code.
I think those would also be useful for FLOSS projects, if you
ship a compiled binary and don't want to recompile the code.
This is the case for example for very huge projects which take
long to compile (think in WebKit or Eigen3 dimensions), or for
Linux distributions which want to separate as much code as
possible and prevent code duplication and statically linked stuff
to make security uploads easier and faster.
(2) Linking against installed libraries
The compilers can of course link against pre-compiled D
libraries. IIRC dub does not have integrated support for this.
The real problem is the D compilers are not ABI compatible.
Urgh...
If you built a library with GDC you can't use it with LDC or
DMD. This is one reason why dub compiles everything from
source. (Even different frontend versions can sometimes break
ABI compatibility).
Is there any way this can be fixed?
https://dlang.org/spec/abi.html gave me the impression D has a
defined ABI the compilers adhere too (which would be a great
advantage over C++).
Fixing this would be pretty useful, not only for the distro
usecase, I think.
Thanks for the explanations, this is useful to know and helps me
to work around some of the issues short-term (long-term we would
really need a solution for these issues, since this will become a
huge issue if/when more D code makes it into distros).
