I have reached conceptual agreement with dmd package maintainer (Sven-Hendrik Haase), new PKGBUILD's are written and change is planned together with 2.063 release.

Important stuff to be aware of (mostly important to AUR packagers):

* dmd now provides virtual package "d-compiler" of version that matches dmd front-end version
* package is now built based on matching github branch. Any tools that did not have source code available is removed.
* new package "dtools" is added. Not only rdmd was moved there but also all tools from D-Programming-Language/tools that make sense for end user will be there (including DustMite!)
* dtools does not have strict dependency on dmd, only on "d-compiler"

As it may be obvious, general direction is to decouple D tool chain and make it possible to install gdc, ldc and dmd at the same time globally with no conflicting binaries. Next goal is generalizing dependecies for Phobos but this needs extensive testing and is delayed.

Please tell me if this is going to cause any issues, it is not that late to make some tweaks.

On Saturday, 18 May 2013 at 09:17:08 UTC, Dicebot wrote:
> I have reached conceptual agreement with dmd package maintainer (Sven-Hendrik Haase), new PKGBUILD's are written and change is planned together with 2.063 release.
>
> Important stuff to be aware of (mostly important to AUR packagers):
>
> * dmd now provides virtual package "d-compiler" of version that matches dmd front-end version
> * package is now built based on matching github branch. Any tools that did not have source code available is removed.
> * new package "dtools" is added. Not only rdmd was moved there but also all tools from D-Programming-Language/tools that make sense for end user will be there (including DustMite!)
> * dtools does not have strict dependency on dmd, only on "d-compiler"
>
> As it may be obvious, general direction is to decouple D tool chain and make it possible to install gdc, ldc and dmd at the same time globally with no conflicting binaries. Next goal is generalizing dependecies for Phobos but this needs extensive testing and is delayed.
>
> Please tell me if this is going to cause any issues, it is not that late to make some tweaks.

Hello.

Thank you for doing this.

Got couple questions:

Will be shared library installed alongside with static library?
Will libdruntime.so belong to druntime package?

I've modified dmd-git package: http://dpaste.dzfl.pl/792e3abc so I've got shared druntime and phobos but currently there is somekind of weird build process going on... it is required to build phobos first in order to get libdruntime.so

Regards,

On Saturday, 18 May 2013 at 14:19:08 UTC, nazriel wrote:
> Will be shared library installed alongside with static library?

Yes.

> Will libdruntime.so belong to druntime package?

No. Currently there is no separate druntime package as druntime is part of phobos binary. This will be a separate issue to address when I'll start decoupling Phobos.

> I've modified dmd-git package: http://dpaste.dzfl.pl/792e3abc so I've got shared druntime and phobos but currently there is somekind of weird build process going on... it is required to build phobos first in order to get libdruntime.so

You can have a look at PKGBUILD drafts for upcoming packages here : https://github.com/Dicebot/Arch-PKGBUILDs for insight. Actually simply changing version there from "master" to "2.063" and back makes all the difference between dmd-git and upcoming release : )

On Saturday, 18 May 2013 at 15:26:49 UTC, Dicebot wrote:
> On Saturday, 18 May 2013 at 14:19:08 UTC, nazriel wrote:
>> Will be shared library installed alongside with static library?
>
> Yes.
>
Cool!

>> Will libdruntime.so belong to druntime package?
>
> No. Currently there is no separate druntime package as druntime is part of phobos binary. This will be a separate issue to address when I'll start decoupling Phobos.
>
Yeah, this "druntime is part of phobos binary" business sux.
I guess druntime and phobos make files would require tweaking in order to allow building druntime as standalone library.

On other hand, AFAIK both LDC and GDC uses modified version of druntime. That would require 3 different packages for druntime. Be it: gdc-druntime, ldc-druntime and dmd-druntime - wonder if this could be improved somehow

>> I've modified dmd-git package: http://dpaste.dzfl.pl/792e3abc so I've got shared druntime and phobos but currently there is somekind of weird build process going on... it is required to build phobos first in order to get libdruntime.so
>
> You can have a look at PKGBUILD drafts for upcoming packages here : https://github.com/Dicebot/Arch-PKGBUILDs for insight. Actually simply changing version there from "master" to "2.063" and back makes all the difference between dmd-git and upcoming release : )

Very nice!

On 5/18/13 8:59 AM, nazriel wrote:
> On Saturday, 18 May 2013 at 15:26:49 UTC, Dicebot wrote:
>> On Saturday, 18 May 2013 at 14:19:08 UTC, nazriel wrote:
>>> Will be shared library installed alongside with static library?
>>
>> Yes.
>>
> Cool!
>
>>> Will libdruntime.so belong to druntime package?
>>
>> No. Currently there is no separate druntime package as druntime is
>> part of phobos binary. This will be a separate issue to address when
>> I'll start decoupling Phobos.
>>
> Yeah, this "druntime is part of phobos binary" business sux.
> I guess druntime and phobos make files would require tweaking in order
> to allow building druntime as standalone library.
>
> On other hand, AFAIK both LDC and GDC uses modified version of druntime.
> That would require 3 different packages for druntime. Be it:
> gdc-druntime, ldc-druntime and dmd-druntime - wonder if this could be
> improved somehow

I fully agree with the desire to make the compilers interchangeable like this, but practical reality is that they aren't.  Trying to pretend they are and making it look like they are to end users is just going to lead to frustration and disappointment, I suspect.

You cannot take the output or runtime from any of the three and use it with any other of the three's outputs (except maybe in some of the most trivial examples).  Hopefully one day, but that day isn't here yet.

On 18 May 2013 20:09, Brad Roberts <braddr@puremagic.com> wrote:

> On 5/18/13 8:59 AM, nazriel wrote:
>
>> On Saturday, 18 May 2013 at 15:26:49 UTC, Dicebot wrote:
>>
>>> On Saturday, 18 May 2013 at 14:19:08 UTC, nazriel wrote:
>>>
>>>> Will be shared library installed alongside with static library?
>>>>
>>>
>>> Yes.
>>>
>>>  Cool!
>>
>>  Will libdruntime.so belong to druntime package?
>>>>
>>>
>>> No. Currently there is no separate druntime package as druntime is part of phobos binary. This will be a separate issue to address when I'll start decoupling Phobos.
>>>
>>>  Yeah, this "druntime is part of phobos binary" business sux.
>> I guess druntime and phobos make files would require tweaking in order to allow building druntime as standalone library.
>>
>> On other hand, AFAIK both LDC and GDC uses modified version of druntime. That would require 3 different packages for druntime. Be it: gdc-druntime, ldc-druntime and dmd-druntime - wonder if this could be improved somehow
>>
>
> I fully agree with the desire to make the compilers interchangeable like this, but practical reality is that they aren't.  Trying to pretend they are and making it look like they are to end users is just going to lead to frustration and disappointment, I suspect.
>
> You cannot take the output or runtime from any of the three and use it with any other of the three's outputs (except maybe in some of the most trivial examples).  Hopefully one day, but that day isn't here yet.
>
>
Agreed.  I had this discussion recently too along the topic of:  Should we allow people to install libphobos/libdruntime in a common library directory, or keep it private as an integral part of the compiler?   IMO, giving given it's close ties between the two, it should always be integral, and the idea of linking against libphobos from an application written in something other than D is still not in any way feasible task.

-- 
Iain Buclaw

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

On Saturday, 18 May 2013 at 19:19:10 UTC, Iain Buclaw wrote:
> Agreed.  I had this discussion recently too along the topic of:
>  Should we
> allow people to install libphobos/libdruntime in a common library
> directory, or keep it private as an integral part of the compiler?   IMO,
> giving given it's close ties between the two, it should always be integral,
> and the idea of linking against libphobos from an application written in
> something other than D is still not in any way feasible task.

I thought about asking your advice on this topic but it was not urgent enough :) What currently prevents having different runtimes but single phobos library for different compilers? How hard is such setup to achieve?

On Saturday, 18 May 2013 at 19:22:36 UTC, Dicebot wrote:
> I thought about asking your advice on this topic but it was not urgent enough :) What currently prevents having different runtimes but single phobos library for different compilers?

Besides other issues, the most fundamental is that the various D compilers are actually not ABI-compatible.

> How hard is such setup to achieve?

Very.

David

On Saturday, 18 May 2013 at 19:54:26 UTC, David Nadlinger wrote:
> Besides other issues, the most fundamental is that the various D compilers are actually not ABI-compatible.

Oh shi~. New discoveries every day. That is.. inconvenient. Kind of delays any possibility of proper packaging a lot. I am surprised that D compilers repeat the very same crucial mistake C++ did. Are there any practical reasons for this other than no one actually cared to keep ABI synced?

On 18 May 2013 21:02, Dicebot <m.strashun@gmail.com> wrote:

>   Are there any practical reasons for this other than no one actually
> cared to keep ABI synced?
>

The D ABI used by DMD is bespoke, and there are some problems in 64bit C
ABI.
LDC afaik has a half and half situation which is no good to anyone.
GDC uses whatever is the default for it's target, which is infact C ABI.

GDC and LDC C ABI may differ, ymmv depending on what you are testing this on.


Also, GDC/LDC/DMD32/DMD64 use different portions of the druntime.  For instance, if you are concatenating two arrays  (a[] ~= b[];) and compile the application with DMD 32bit, and linked to a druntime built by GDC then you'll get undefined references to '_d_arrayappendcT' (for GDC, this function is useless as is not portable, so we version it out)

There are some other hidden implementation details such as the magical thread local vars differ between platforms on DMD, but remain the same on GDC, etc, etc, yada, yada...


-- 
Iain Buclaw

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