On Wed, 17 Oct 2012 15:03:41 +0300 Manu <turkey...@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.