Arch Linux users and packagers : upcoming coomunity/dmd package change

2013-05-18 Thread Dicebot
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.


Re: Arch Linux users and packagers : upcoming coomunity/dmd package change

2013-05-18 Thread nazriel

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,


Re: Arch Linux users and packagers : upcoming coomunity/dmd package change

2013-05-18 Thread Dicebot

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 : )


Re: Arch Linux users and packagers : upcoming coomunity/dmd package change

2013-05-18 Thread nazriel

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!


Re: Arch Linux users and packagers : upcoming coomunity/dmd package change

2013-05-18 Thread Brad Roberts

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.




Re: Arch Linux users and packagers : upcoming coomunity/dmd package change

2013-05-18 Thread Iain Buclaw
On 18 May 2013 20:09, Brad Roberts bra...@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';


Re: Arch Linux users and packagers : upcoming coomunity/dmd package change

2013-05-18 Thread Dicebot

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?


Re: Arch Linux users and packagers : upcoming coomunity/dmd package change

2013-05-18 Thread David Nadlinger

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


Re: Arch Linux users and packagers : upcoming coomunity/dmd package change

2013-05-18 Thread Iain Buclaw
On 18 May 2013 21:02, Dicebot m.stras...@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';