make install; where do .di files go?

[Nick Sabalausky]

On Wed, 17 Oct 2012 15:03:41 +0300
Manu <turkeyman at gmail.com> wrote:
> 
> Well let's attempt to begin that process in that case :)
> 

I agree.

> why include/d2? include/d/ seems much better... what are the chances a
> library have both a d1 and d2 version which may conflict in include/d?
> 

While this doesn't solve the issue of multiple versions of the same lib,
I think "multiple versions of the same lib" is an issue that can't be
properly solved until we have a standard package manager, anyway.

So my vote goes for sticking everything (*except* phobos and druntime
since those are tied to a specific version of the compiler)
into /usr/include/d2

I don't think we should be remotely worried about calling it "d2",
because really the whole "D2 is now called D" thing is little more than
a marketing/branding/defaults matter, and we're not talking about
evangelizing D here, we're just talking about a technical
implementation matter. And even if "D" now means "D2" by default, the
D1/D2 monikers are still very useful when disambiguation is needed,
which is exactly the case here. (I don't see Pythoners worrying about
"Let's avoid calling v3.x 'Python 3'.")

And even if one *could* argue that there's little chance of technical
conflicts, using '/usr/include/d2' *guarantees* there won't be any
conflicts, and doesn't cause any real problem, so the whole question
becomes completely irrelevant anyway. '/usr/include/d' might have
issues, '/usr/include/d2' *will work*, period. So I say let's just go
with '/usr/include/d2' and be done with it. Then we can get around to
adding a proper package manager later to solve the "multiple versions
of the same lib", but in the meantime at least we've made progress.