On 18 October 2012 09:22, David Nadlinger <see@klickverbot.at> wrote:
On Wednesday, 17 October 2012 at 23:33:44 UTC, Manu wrote:
That I support his comments and suggestion.
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.
Well,
1) if there IS legitimate concern of conflict with D1, then it must be /d2, I'm just dubious that any conflict would actually exist, and new-comers (ideally, the majority of the community in the future) would probably presume /d and wonder what this /d2 is all about. Someone mentioned the tango object.di case... I don't know anything about that, but I'll presume others know better than me.
and 2) I don't really care where it is, I would just like an answer that is agree'd by the various compilers, and which is included in each of their search paths by default. How can one make a build script for their apps when it's not consistent where libraries are to be found?
A package manager is all well and good, but it doesn't exist yet. We need to nominate a standard path in the mean time.
I don't have to go adding -I/usr/include when compiling C code, that's the point. If a lib was installed by some standard distribution, you should just be able to use it in your app without trouble. This is particularly important when dealing with D bindings for C libs, since it basically has to work within the C conventions to find the lib, the headers should be distributed similarly.