On Wed, 17 Oct 2012 19:42:25 +0300
Manu <turkeyman@gmail.com> wrote:
> 
> 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.
> 

Not really, it just means it's part of the v2.x line. Debian 6 doesn't mean that Debians 1-5 were failures. Lots of software has breaking revisions with a new major version number, and so then sometimes you need to disambiguate.

On Wed, 17 Oct 2012 15:03:41 +0300
Manu <turkeyman@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.

On Wednesday, 17 October 2012 at 21:39:15 UTC, Nick Sabalausky wrote:
> 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

That's also what I do for Thrift.

David

On 10/17/2012 05:39 PM, Jordi Sayol 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.
>
> 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.
>

Is there any chance of getting the package changed?

-- 
Mike Wey

Al 18/10/12 00:03, En/na Mike Wey ha escrit:
>> 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.
>>
> 
> Is there any chance of getting the package changed?
> 

Don't know, this is the link to the debian source page: http://packages.debian.org/source/sid/libtango

-- 
Jordi Sayol

On 18 October 2012 00:39, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> On Wed, 17 Oct 2012 15:03:41 +0300
> Manu <turkeyman@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.

On Wednesday, 17 October 2012 at 23:08:32 UTC, Manu wrote:
> Hear hear.

At least to me, it is not at all clear what you are trying to imply with this comment.

David

On 18 October 2012 02:12, David Nadlinger <see@klickverbot.at> wrote:

> On Wednesday, 17 October 2012 at 23:08:32 UTC, Manu wrote:
>
>> Hear hear.
>>
>
> At least to me, it is not at all clear what you are trying to imply with this comment.


That I support his comments and suggestion.

On Thu, 18 Oct 2012 01:12:45 +0200
"David Nadlinger" <see@klickverbot.at> wrote:

> On Wednesday, 17 October 2012 at 23:08:32 UTC, Manu wrote:
> > Hear hear.
> 
> At least to me, it is not at all clear what you are trying to imply with this comment.
> 

http://en.wikipedia.org/wiki/Hear_hear

On Wednesday, 17 October 2012 at 23:33:44 UTC, Manu wrote:
> That I support his comments and suggestion.

Oh, really just that then. I wasn't quite sure if you were still
worried about

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

David