On 17 October 2012 18:39, Jordi Sayol <span dir="ltr"><<a href="mailto:g.sayol@yahoo.es" target="_blank">g.sayol@yahoo.es</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">
Al 17/10/12 14:03, En/na Manu ha escrit:<br>
<div class="im">><br>
> 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?<br>
><br>
<br>
</div>A practical example:<br>
Imagine that you installs the libray "foo" for D, and places the sources at "/usr/include/d/foo" directory, <b>so you need to add "-I/usr/include/d" as compiler argument</b>.<br></blockquote>
<div><br></div><div>No, I don't need to add it as an argument, that's the point.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<br>
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.<br>
</blockquote><div><br></div><div>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.</div>
</div>