On 18 October 2012 00:39, Nick Sabalausky < seewebsitetocontac...@semitwist.com> wrote:
> 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. > Hear hear.