FS#48830 - [libphobos] [libphobos-devel] [liblphobos] [libgphobos-devel] Consistency of d-stdlib
Attached to Project:
Community Packages
Opened by Davi da Silva Böger (dsboger) - Thursday, 07 April 2016, 03:50 GMT
Last edited by Mihails Strasuns (Dicebot) - Thursday, 14 April 2016, 11:14 GMT
Opened by Davi da Silva Böger (dsboger) - Thursday, 07 April 2016, 03:50 GMT
Last edited by Mihails Strasuns (Dicebot) - Thursday, 14 April 2016, 11:14 GMT
|
Details
I'm co-maintaining AUR packages gtkd and gtkd-git and we
would like to make building the packaged libraries
independent of the D compiler the user has installed. For
that we can makedepend on d-compiler and all is well. The
problem, though, is that we intend to build shared
libraries, so gtkd and gtkd-git must both depend and
makedepend on d-stdlib, but in some cases d-stdlib installs
only static libraries (libphobos-devel and
libgphobos-devel).
I would like to propose (and offer help to) simplifying the packaging of d-stdlib for the three compilers by providing three packages: libphobos, liblphobos and libgphobos, all of them providing d-stdlib and including both static and shared libraries. It would make d-stdlib consistent and not only gtkd, but also other D packages could be made "compiler agnostic". I don't know much of D, and even less about the idiosyncrasies of each compiler, so that proposal might even not be achievable. Please, let me know what you think. Thanks! |
This task depends upon
Closed by Mihails Strasuns (Dicebot)
Thursday, 14 April 2016, 11:14 GMT
Reason for closing: Not a bug
Thursday, 14 April 2016, 11:14 GMT
Reason for closing: Not a bug
All D compilers release with a different rate - current DMD is at 2.071.0, last stable LDC uses frontend version 2.068.2 and GDC is still based on 2.066.1 frontend version (with 2.067 support to come soon). What make your task even more problematic, ABI between compilers is not compatible at all - i.e. you can't take application built with DMD and link it to Phobos provided by GDC even if their frontend version match. It all needs to stay in sync.
What I tend do myself is to build package using one "main" compiler (usually LDC) but to write PKGBUILD in a way that anyone can easily tweak it to use different compiler with one or two lines of changes at most. See, for example, this little helper script to find our current installed d-compiler : https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/d-compiler.sh
I am open to any improvement proposals that are achievable though :)
Of course, our D packages are in AUR. If they were binary distributions, then we would probably have to stick to a single d-compiler/d-stdlib for everything D, like gcc/glibc for C.
Thanks again.
This is currently blocked on https://github.com/ldc-developers/ldc/pull/1305 , see also https://bugs.archlinux.org/task/48028?project=5&dev=16300 (I can't add static lib support without breaking existing shared lib support because there is no easy way in LDC to switch between them), hopefully will be finished by the next LDC release and I'll modify LDC package to provide both.
> shared libs for libgphobos-devel
You probably mean libgphobos - shared libraries are kept in separate packages from `-devel` so that packages can use them as runtime dependency as opposed to build one. Does GDC currently suppport shared libraries? Last time I checked, it haven't, any links on topic are appreciated. This is also why I can't do this:
> while also merging static and shared into a single package
.. as otherwise build time dependencies and run time dependencies would be mixed into one. This is also why you can't write generic PKBUILD with support of any shared library - you need to specific exact matching shared standard library package in `depends` array.
However, making one PKGBUILD which works for static build with any compiler in the system is relatively simple. All you need is to add `d-compiler` and `d-stdlib` to `makedepends` and use the https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/d-compiler.sh script to find which one to use in build script itself as DC.
As for splitting/merging static and shared libs, I don't have a strong stance, really. glibc installs both, so I thought: "why not the same for D?".
Thanks again for clarifying!