Distributor's whishlist and questions for D

[Johannes Pfau via Digitalmars-d]

On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote:
> ## Where should D source-code / D interfaces be put?
> If I install a D library or source-only module as a 
> distribution package, where should the sources be put? So far, 
> I have seen:
>  * /usr/include/d
>  * /usr/include/dlang/
>  * /usr/include/d/(dmd|gdc|ldc)
>  * /usr/share/dlang
> Having one canonical path would be awesome ;-)

/usr/include/d or /usr/include/dlang. I prefer /usr/include/d as 
it's shorter, but the important point is that we need to decide 
on a common standard.

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

> ## 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. Otherwise 
you probably need /var/cache or /var/lib or somehting like that. 
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.


> ## 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 or do you 
want dub-style support for multiple library versions which means 
you need to compile everything through dub.

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.