Am Tue, 11 Apr 2017 07:44:45 -0700 schrieb Jonathan M Davis via Digitalmars-d <digitalmars-d@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