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