make install; where do .di files go?

Manu turkeyman at gmail.com
Wed Oct 17 05:08:13 PDT 2012


On 17 October 2012 12:28, Nick Sabalausky <
SeeWebsiteToContactMe at semitwist.com> wrote:

> On Tue, 16 Oct 2012 14:56:02 -0700
> "H. S. Teoh" <hsteoh at quickfur.ath.cx> 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" <hsteoh at quickfur.ath.cx> 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
> > > > > <g.sayol at yahoo.es> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121017/e534b911/attachment.html>


More information about the Digitalmars-d mailing list