The D ecosystem in Debian with free-as-in-freedom DMD

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Tue Apr 11 14:08:05 PDT 2017


Am Tue, 11 Apr 2017 07:44:45 -0700
schrieb Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com>:

> On Tuesday, April 11, 2017 14:33:01 Matthias Klumpp via Digitalmars-d
> wrote:
> > On Tuesday, 11 April 2017 at 14:26:37 UTC, rikki cattermole wrote:  
> > > [...]
> > > The problem with /usr/include/d is that is where .di files
> > > would be located not .d. This would also match up with the
> > > c/c++ usage of it.  
> >
> > When I asked about this a while back, I was told to just install
> > the sources into the include D as "almost nobody uses .di files
> > except for proprietary libraries" (and do those even exist?).
> > But in any case, any path would be fine with me as long as people
> > can settle on using it - `/usr/share/d` would be available ^^  
> 
> Putting .di files in the include directory makes sense when compared
> to C++, but it's definitely true that they're used quite rarely. They
> gain you very little and cost you a lot (e.g. no CTFE). But unless
> someone were looking to put both .di and .d files for the same module
> on the same system, it wouldn't really be an issue to put them both
> in the include directory. I would expect open source librares to
> use .di files very rarely though.
> 
> - Jonathan M Davis
> 

I'd think of .d files as a superset of .di files. There's no reason to
install both (assuming same library version) and having the .d files
will produce better cross-module inlining so these are preferred.

Of course for proprietary libraries .di files are required. But
nevertheless .di and .d can be mixed in /usr/include/d.

The only downside is that inlining from /usr/include could cause
licensing problems (e.g. LGPL allows only linking, not sure how
inlining would be affected. But it seems they have an Exception for
inlining)


-- Johannes



More information about the Digitalmars-d mailing list