Distributor's whishlist and questions for D

[Matthias Klumpp via Digitalmars-d]

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