On Friday, 15 April 2016 at 09:15:05 UTC, Johannes Pfau wrote:
Am Thu, 14 Apr 2016 23:16:49 +0000
schrieb Matthias Klumpp <[email protected]>:
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:
[...]
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.
Or when the source-code is very large, I guess. But the way D
handles this makes much sense to me!
[...]
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.
Yeah, and this makes D pretty hard to sell to distributors. While
I would argue that for applications it is no longer essential to
be packages and shipped by distributions (or rather it won't be
in future), for a "new" programming language this is a crucial
thing.
As soon as it is easy to try out for developers, more people will
"just try it" and maybe stick with it. If testing it is hard due
to incompatible standard libraries, runtimes, or simply missing
free D compilers, people won't try it.
In fact, that it also is pretty hard for people to compile
applications written in D on distributions other than Debian (and
even there it was not without issues...) was *the* biggest
concern for me.
This needs coordinated work from all compiler teams though. For
GDC I'll finally have to finish shared library support first...
That would be awesome to have! Thank you for working on this!
