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

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.

I was thinking of it as forward thinking way of doing things (taking my
queue from python for which multiple version do end up being installed on
most peoples systems).
I would make /usr/include/d1 for d version 1 files /usr/include/d2 for
version 2 /usr/include/d3 for version 3 etc.
/usr/include/d should be a symlink that points to what is concidered the
current version of the language.

I am not saying that it is the best way to do things but that is my thinking.

On Thursday, 18 October 2012 at 07:29:45 UTC, Manu wrote:
> 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?

Just an aside: During the whole discussion, please don't forget that you also need to compile your library separately for each compiler, as long as they are not ABI compatible (which is still a long way out). Thus, while I don't think a standard import path wouldn't be nice to have, the issue doesn't stand out as a single big problem as it might seem at first.

David

Al 18/10/12 11:21, En/na David Nadlinger ha escrit:
> On Thursday, 18 October 2012 at 07:29:45 UTC, Manu wrote:
>> 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?
> 
> Just an aside: During the whole discussion, please don't forget that you also need to compile your library separately for each compiler, as long as they are not ABI compatible (which is still a long way out). Thus, while I don't think a standard import path wouldn't be nice to have, the issue doesn't stand out as a single big problem as it might seem at first.
> 
> David
> 

+1

-- 
Jordi Sayol

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

> On Thursday, 18 October 2012 at 07:29:45 UTC, Manu wrote:
>
>> 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?
>>
>
> Just an aside: During the whole discussion, please don't forget that you also need to compile your library separately for each compiler, as long as they are not ABI compatible (which is still a long way out). Thus, while I don't think a standard import path wouldn't be nice to have, the issue doesn't stand out as a single big problem as it might seem at first.


Really? The D compilers aren't ABI compatible on Linux? Good to know. Cheers!

Well, for my own purposes, I only intend to interact with bindings for C libs, which, fortunately, are universally binary compatible :)

On 2012-10-18 13:09, Manu wrote:

> Really? The D compilers aren't ABI compatible on Linux?
> Good to know. Cheers!

They all use different runtimes and at least GDC won't implement the D calling convention. GDC uses the calling convention of the backend. GDC also don't implement DMD inline assembly.

-- 
/Jacob Carlborg

On 18 October 2012 14:36, Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-18 13:09, Manu wrote:
>
>  Really? The D compilers aren't ABI compatible on Linux?
>> Good to know. Cheers!
>>
>
> They all use different runtimes and at least GDC won't implement the D calling convention. GDC uses the calling convention of the backend. GDC also don't implement DMD inline assembly.


What's distinct about the D calling convention?

On 18 October 2012 13:24, Manu <turkeyman@gmail.com> wrote:
> On 18 October 2012 14:36, Jacob Carlborg <doob@me.com> wrote:
>>
>> On 2012-10-18 13:09, Manu wrote:
>>
>>> Really? The D compilers aren't ABI compatible on Linux? Good to know. Cheers!
>>
>>
>> They all use different runtimes and at least GDC won't implement the D calling convention. GDC uses the calling convention of the backend. GDC also don't implement DMD inline assembly.
>
>
> What's distinct about the D calling convention?

It distinctly sox. ;-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2012-10-18 14:24, Manu wrote:

> What's distinct about the D calling convention?

GDC uses the C calling convention (or whatever the calling convention used by the system) where DMD uses a slightly modified version, if I recall correctly. Note that DMD only defines an ABI for x86 and possible x86-64.

http://dlang.org/abi.html

-- 
/Jacob Carlborg

On Oct 18, 2012, at 11:45 AM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-18 14:24, Manu wrote:
> 
>> What's distinct about the D calling convention?
> 
> GDC uses the C calling convention (or whatever the calling convention used by the system) where DMD uses a slightly modified version, if I recall correctly. Note that DMD only defines an ABI for x86 and possible x86-64.

On x86_32, the first argument is passed in EAX with the D calling convention.  But DMD is the only compiler that does this.