Official dub packages for Debian and Ubuntu

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 14 Apr 2016 23:16:49 +0000
schrieb Matthias Klumpp <matthias at tenstral.net>:

> On Thursday, 14 April 2016 at 17:46:55 UTC, Johannes Pfau wrote:
> > 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.
> 

I totally agree it makes sense to ship precompiled libraries. But even
with precompiled libraries you can still ship the full source code
instead of header files. An example:

a/foo.d:
------------------------------------------------
module foo;
int fooFunc() {return 42;}
------------------------------------------------

=> dmd -H a/foo.d => b/foo.di
------------------------------------------------
// D import file generated from 'foo.d'
module foo;
int fooFunc();
------------------------------------------------

dmd -lib a/foo.d -oflibfoo.a

main.d
------------------------------------------------
import foo;
void main(){fooFunc()}
------------------------------------------------

// We need foo.di or foo.d in the import path
dmd main.d -L-L. -L-lfoo
main.d(1): Error: module foo is in file 'foo.d' which cannot be read

// This uses the foo.di header
dmd main.d -L-L. -L-lfoo -Ib

// This uses foo.d as a header, but does _not_ compile foo.d
dmd main.d -L-L. -L-lfoo -Ia


The important point here is that you can use the normal source code as
headers. The source code of a library is not recompiled, it's only used
to parse function definitions and similar stuff. The compilation speed
should be very similar for .d and .di files as well. The benefit of
shipping the complete source code is that fooFunc can be inlined into
main.d with the foo.d source, but not with foo.di.

Shipping .di files only makes sense if you have to hide the source
code.

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

The ABI is partially standardized:
* Name mangling is the same for all compilers.
* D has a special calling convention on X86 windows, but all other
  architectures and all other OS use the C calling convention. The
  compilers should be compatible, but this is something which needs
  some testing. 

* Exception handling: DMD recently implemented DWARF exception
  handling, so the compilers could be compatible but the personality
  functions are not. I'm not sure if the implementations are
  compatible, but not even the function names match
  (__dmd_personality_v0 / __gdc_personality_v0)
* The biggest problem is druntime: we need to make sure that the
  druntime libraries used by different compilers have a compatible ABI.

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

I agree having a common ABI should be prioritized. It's really
annoying for distributions (E.g. archlinux installs druntime/phobos into
different directories /usr/include/dlang/{gdc,dmd,ldc} and never
installs compiled libraries). Shared D libraries are useless in
practice because of this issue.

This needs coordinated work from all compiler teams though. For GDC
I'll finally have to finish shared library support first...