On Tue, 16 Oct 2012 14:56:02 -0700
"H. S. Teoh" <hsteoh@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@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@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 ;)

On 17 October 2012 11:48, Jordi Sayol <g.sayol@yahoo.es> wrote:

> Al 16/10/12 22:37, En/na Nick Sabalausky ha escrit:
> >> Linux dmd deb/rpm packages installs "/etc/dmd.conf" file which contains the modules/interfaces paths. The easiest way to add another path for your library in Linux is to create a "pkg-config" file.
> >
> > Would that be Debian-specific though?
>
> This is Linux and C specific.
> In debian/Ubuntu/LinuxMint, with "libgtk-3-dev" and "pkg-config" packages
> installed, just type:
> $ pkg-config --cflags --libs gtk+-3.0
> You'll get all the sources, libraries and some flags that gcc needs to
> properly compile gtk projects.
>
> >> 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 ;)
> >
>
> Is a possibility, but it must be agreed.
>

Well let's attempt to begin that process in that case :)

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?

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

> On Tue, 16 Oct 2012 14:56:02 -0700
> "H. S. Teoh" <hsteoh@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@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@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?

On 2012-10-17 14:08, Manu wrote:

> 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?

I don't like that approach used by C.

-- 
/Jacob Carlborg

On 17 October 2012 17:09, Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-17 14:08, Manu wrote:
>
>  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?
>>
>
> I don't like that approach used by C.


Well I really, really do.
Infact, that is the single most significant thing that attracts me to linux
rather than windows. The standardised include/lib paths are an absolute win
for linux.

Al 17/10/12 14:03, En/na Manu ha escrit:
> 
> 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?
> 

A practical example:
Imagine that you installs the libray "foo" for D, and places the sources at "/usr/include/d/foo" directory, so you need to add "-I/usr/include/d" as compiler argument.

In Debian/Ubuntu there is the "libtango-headers" package, which install, among others, "/usr/include/d/object.di". This Tango "object.di" breaks d2, so you will not be able to compile anything with the "-I/usr/include/d" argument, and so, you cannot compile against your "foo" library.

The problem here is that the "libtango-headers" maintainer decided to place "object.di" directly into "/usr/include/d", overriding to use this directory for any other D compiler/version.

-- 
Jordi Sayol

On 17 October 2012 18:39, Jordi Sayol <g.sayol@yahoo.es> wrote:

> Al 17/10/12 14:03, En/na Manu ha escrit:
> >
> > 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?
> >
>
> A practical example:
> Imagine that you installs the libray "foo" for D, and places the sources
> at "/usr/include/d/foo" directory, *so you need to add "-I/usr/include/d"
> as compiler argument*.
>

No, I don't need to add it as an argument, that's the point.


In Debian/Ubuntu there is the "libtango-headers" package, which install,
> among others, "/usr/include/d/object.di". This Tango "object.di" breaks d2, so you will not be able to compile anything with the "-I/usr/include/d" argument, and so, you cannot compile against your "foo" library.
>
> The problem here is that the "libtango-headers" maintainer decided to place "object.di" directly into "/usr/include/d", overriding to use this directory for any other D compiler/version.
>

Okay, so the problem is that an existing package has already declared that directory to be a standard location. so then include/d2/ then... I guess. Although that seems sad; D shouldn't identify its self as the second coming of D, since that basically implies that the first coming was a failure.

On 2012-10-17 16:13, Manu wrote:

> Well I really, really do.
> Infact, that is the single most significant thing that attracts me to
> linux rather than windows. The standardised include/lib paths are an
> absolute win for linux.

I completely sold how the package manager works in Ruby and together with Bundler. With Bundler you need to explicitly say that you want access to a particular package, otherwise you cannot import/include it.

This work out beautifully and you can have how many packages and different versions of the same package as you want, with very slim chance of a conflict.

-- 
/Jacob Carlborg

On 2012-10-17 18:42, Manu wrote:

> since that basically implies that the first coming
> was a failure.

That is just as sad.

-- 
/Jacob Carlborg

On Wed, 17 Oct 2012 15:08:13 +0300
Manu <turkeyman@gmail.com> wrote:

> On 17 October 2012 12:28, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> > On Tue, 16 Oct 2012 14:56:02 -0700
> > "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> > >
> > > 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?
> 

I was referring to the "How else would you have multiple versions of the same lib". If all libs are put into the same directory, then you can't have multiple versions of the same one without giving each version a different name. I wouldn't want to have to search/replace all "import foobar-1-0;" with "import foobar-1-11;" everytime I upgrade a lib.

I guess what you could do is have a directory structure like this:

/usr/include/d2/foobar/1.0/foobar.d /usr/include/d2/foobar/1.7/foobar.d /usr/include/d2/foobar/2.1/foobar.d

But then you'd still have to use -I... when you import anything, which removes some of the benefit of having one standard installation directory for libs. But I guess that is still an improvement over just not having any standard install directory.