On 17 October 2012 12:28, Nick Sabalausky < [email protected]> wrote:
> On Tue, 16 Oct 2012 14:56:02 -0700 > "H. S. Teoh" <[email protected]> wrote: > > > On Tue, Oct 16, 2012 at 05:45:07PM -0400, Nick Sabalausky wrote: > > > On Tue, 16 Oct 2012 14:00:32 -0700 > > > "H. S. Teoh" <[email protected]> wrote: > > > > > > > On Tue, Oct 16, 2012 at 04:37:32PM -0400, Nick Sabalausky wrote: > > > > > On Tue, 16 Oct 2012 17:48:54 +0200 Jordi Sayol > > > > > <[email protected]> wrote: > > > > > > > > > > > > Linux dmd will not include /usr/include/d path by default to > > > > > > avoid conflicts with ldc1 (tango) "object.di" incompatibility, > > > > > > and I recommend you to not use this path for that reason. > > > > > > > > > > > > > > > > Then we can use '/usr/include/d2'. Problem solved ;) > > > > > > > > I propose /usr/include/d/${version}/. It will make it possible for > > > > multiple versions of dmd to coexist, as well as eliminate version > > > > incompatibility problems (or at least make them very unlikely). > > > > > > > > Mixing everything in /usr/include/d (or /usr/include/d2) with the > > > > fact that dmd releases have been incompatible with older > > > > druntime/phobos is just asking for trouble. > > > > > > > > > > If by ${version} you mean 2.059, 2.060, etc., then I don't like > > > that. I don't want to have to have the same library installed > > > separately for every version of DMD on my system. That's just a > > > mess. > > > > If you have multiple versions of DMD sharing the same /usr/include/d, > > that's even more of a mess. > > > > Of course, ideally, when you upgrade DMD it will also uninstall the > > older stuff so that you don't have like 50 stale copies of > > druntime/phobos after upgrading 50 times. That's something for the > > package manager to take care of. :-P > > > > Well, if you're talking about phobos/druntime, then I agree since those > are tied to the compiler they come with. But I was talking about third > party libs. I think it may be good to keep a separation for D1 libs vs > D2 libs, but not (for example) 2.059 vs 2.060 (except, of course, for > phobos and druntime). > > Of course, I'm not sure separate 2.059 vs 2.060 (etc...) dirs for > third-party libs would even work at all, because how are you going to > tell (for example) a xxxx.deb file which compiler's dir to install > into? Give your lib a separate .deb for each version of DMD? > "dlibfoobar-dmd-2.059.deb", "dlibfoobar-dmd-2.060.deb"...etc? > > > > > > A way to have multiple versions of the same lib would be good > > > though. Although that's one of the reasons I prefer to just use -I > > > instead of messing with system-wide installation anyway. > > > > How else would you have multiple versions of the same lib, though? > > They can't all live in the same place since files will conflict. > > > > Unfortunately, I see only two realistic possibilities: > > A. Forget about system-wide lib installation and pass -I... to the > compiler for each lib you're using. Kind of a pain but... > > B. Wait for a proper D package manager. > > Personally, I choose "A", at least for the time being ;) > What about C: Nominate a place, just like C does?? I don't see the problem. Where is the essential difference from system-wide installed C libraries?
