Hi, and thanks for your detailed explanations!
On Thursday, 21 April 2016 at 11:49:13 UTC, Johannes Pfau wrote:
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp
wrote:
[...]
You currently can't install druntime or phobos headers in this
directory, as each compiler will have slightly modified
versions and then you end up with /usr/include/d/(dmd|gdc|ldc).
That doesn't seem to be the case for LDC on Debian... It installs
Phobos into /usr/include/d/std, which makes GDC go crazy as soon
as LDC is installed too.
I suspect this is a packaging bug, if so, I'll report a bug
against LDC.
But all other library headers should be shareable between
compilers and can be placed in /usr/include/d. (This might even
work for phobos, I don't think we have many compiler specific
changes there. But then you need to use the same frontend
version for all compilers.)
This is probably a very naive question, but: Isn't the D
specification finished? If the language is done, why would there
be a dependence of Phobos on a specific compiler?
Or is this because the new code in Phobos might expose bugs in
the compiler itself, which causes these incompatibilities?
You can only install headers for one library version with this
approach! A versioned approach is nicer
/usr/include/d/libfoo/1.0.0 but requires explicit compiler
support and it's unlikely this will happen (or explicit dub
support and you compile everything through dub).
Would be nice, but since we - most of the time - only allow one
version of a specific software package to be present in
distributions, it isn't a huge issue.
## dub: Where should dub modules be installed?
What does FHS recommend in this case? If you only keep
headers/sources you could install into /usr/include.
By the FHS, /usr/include/d should be okay for headers (well, the
spec explicitly says C programming language headers, but well....
:P).
Otherwise you probably need /var/cache or /var/lib or somehting
like that.
/var/cache and /var/lib are forbidden for distributors, since
they contain state information which shouldn't be touched (as
always, there are exceptions...).
If the dub packages contain architecture-independent stuff only,
they need to go to /usr/share/dlang or /usr/include/d, and the
shared or static library must go to /usr/lib/<triplet>/.
If you split packages you could use the standard /usr/lib*
folders but then you need to keep versioned subdirectories to
support installing multiple versions.
Multiple versions would be a rare event, since no distro package
management system allows that (excluding Nix here, which is kind
of special).
Installing arbitrary arch-specific content into a subdirectory in
/usr/lib is fine too, but I doubt that will be necessary...
## dub: How to install modules?
Ideally, dub would also have a "dub install" command, to
install the binary, "headers (.di)"/sources and data into
standard directories on Linux.
(reported as https://github.com/dlang/dub/issues/811 )
See above. The main question is: Do you want to have a C style
install of one version of a library and have gdc find the
includes and library when running gdc main.a -libfoo
For plain gdc/ldc, I'd say: yes
or do you want dub-style support for multiple library versions
which means you need to compile everything through dub.
For stuff using dub, I'd say yes to that too ;-)
I'd love to have some extended compiler support (so you could
simply do gdc -use=libfoo:1.0.0 and this would pick up the
correct headers and linker flags). But as some DMD maintainers
are opposed to this idea it won't happen. You'll probably
always need dub for a 'nice' user interface.
++++++
Aside from these things, there are also some other things
which would be very useful:
## Shared library support in all compilers
This is mainly a GDC issue. DMD and LDC support shared libs,
although I don't think these libraries are ABI compatible.
Sounds more and more like LDC is - at time - the better choice
over GDC...
