www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Arch Linux users and packagers : upcoming coomunity/dmd package change

reply "Dicebot" <m.strashun gmail.com> writes:
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.
May 18 2013
parent reply "nazriel" <spam dzfl.pl> writes:
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,
May 18 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
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 : )
May 18 2013
parent reply "nazriel" <spam dzfl.pl> writes:
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!
May 18 2013
next sibling parent Brad Roberts <braddr puremagic.com> writes:
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.
May 18 2013
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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';



 May 18 2013



  parent reply "Dicebot" <m.strashun gmail.com>  writes:


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?



 May 18 2013



  parent reply "David Nadlinger" <see klickverbot.at>  writes:


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



 May 18 2013



  parent reply "Dicebot" <m.strashun gmail.com>  writes:


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?



 May 18 2013



  parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


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';



 May 18 2013