On Monday, 17 November 2014 at 02:29:54 UTC, Marco Leise wrote:
> Exactly a year ago I created a poll[1] about the include path
> and 65% voted for "dlang" over just "d". We should stick to
> "/usr/include/dlang" now for a consistent experience across
> distributions. Compilers' import paths are less of an issue as
> they are either built-in or configured in dmd.conf. But for
> build tools it would be nice if imports for library X could
> always be found in "/usr/include/dlang/X/".

Fair enough, although if the issue with different compilers making a different ABI persists, then wouldn't it be a good idea to put it into /usr/include/{dmd,gdc,ldc} or something?

But otherwise I pinged some people on openSUSE and it seems there is some interest in D, so now we have a separate project for it. Maintaining a separate libphobos2 doesn't look very hard after all.

Though I'm still a bit unsure about the whole druntime part. The official RPM doesn't include any libraries for druntime, only includes, albeit building it from source does produce a druntime library. Is it worth separating it out into its own package? Or should it be part of dmd-devel instead? (druntime-devel doesn't really sound right if there is no actual druntime package itself...)

On Monday, 17 November 2014 at 19:36:10 UTC, GreatEmerald wrote:
> But otherwise I pinged some people on openSUSE and it seems there is some interest in D, so now we have a separate project for it.

That's great to hear! Duncan Mac-Vicar started work on an LDC packages, which I'm keeping up-to-date since then:
https://build.opensuse.org/package/show/home:marc_schuetz:branches:home:dmacvicar/ldc

I'm going to ask him, and then submit this package to the new project.

I was a bit afraid of what will become of it when we switch to DDMD, because then we'll need to have an already working D compiler, but this project will make it easier.

BTW, I'm unsure how to handle DMD's license:
https://github.com/D-Programming-Language/dmd/blob/master/src/backendlicense.txt

I think we need to ask Walter first before DMD can be put on the OBS.

On Tuesday, 18 November 2014 at 11:14:06 UTC, Marc Schütz wrote:
> That's great to hear! Duncan Mac-Vicar started work on an LDC packages, which I'm keeping up-to-date since then:
> https://build.opensuse.org/package/show/home:marc_schuetz:branches:home:dmacvicar/ldc
>
> I'm going to ask him, and then submit this package to the new project.

Yeap, please do :)

> BTW, I'm unsure how to handle DMD's license:
> https://github.com/D-Programming-Language/dmd/blob/master/src/backendlicense.txt
>
> I think we need to ask Walter first before DMD can be put on the OBS.

Yea, it's a bit of a problem. It would be nice to do that.

On Monday, 17 November 2014 at 19:36:10 UTC, GreatEmerald wrote:
> Though I'm still a bit unsure about the whole druntime part. The official RPM doesn't include any libraries for druntime, only includes, albeit building it from source does produce a druntime library. Is it worth separating it out into its own package? Or should it be part of dmd-devel instead? (druntime-devel doesn't really sound right if there is no actual druntime package itself...)

Answering my own question, looks like libphobos2 statically links to druntime, so those includes should probably be part of libphobos2-devel.

Am Mon, 17 Nov 2014 19:36:08 +0000
schrieb "GreatEmerald" <pastas4@gmail.com>:

> On Monday, 17 November 2014 at 02:29:54 UTC, Marco Leise wrote:
> > Exactly a year ago I created a poll[1] about the include path and 65% voted for "dlang" over just "d". We should stick to "/usr/include/dlang" now for a consistent experience across distributions. Compilers' import paths are less of an issue as they are either built-in or configured in dmd.conf. But for build tools it would be nice if imports for library X could always be found in "/usr/include/dlang/X/".
> 
> Fair enough, although if the issue with different compilers making a different ABI persists, then wouldn't it be a good idea to put it into /usr/include/{dmd,gdc,ldc} or something?

ABI differences in source files only apply to druntime/Phobos
and these imports are generally on the default import path. I
was more concerned with GtkD and similar 3rd party libraries,
for which you have to specify the import path.
Or am I missing a case where 3rd party import files should also
differ for each compiler?

As for the ABI incompatibilities of libraries themselves I'm using -rpath and install them to /opt/<compiler>-<version>/lib or GCC's own version specific library path in case of GDC. My hope is that some day the issue can be settled and this is only a stop-gap measure. (We'd still have a pretty fast changing Phobos and possibly ABI changes due to bug fixes or enhancements, so it is likely we end up with some "dlang-2070" pre- or postfix, but not one library per compiler vendor and Dlang version as it is now.)

-- 
Marco

On Tuesday, 18 November 2014 at 16:26:58 UTC, Marco Leise wrote:
> ABI differences in source files only apply to druntime/Phobos
> and these imports are generally on the default import path. I
> was more concerned with GtkD and similar 3rd party libraries,
> for which you have to specify the import path.

Fair enough, include files shouldn't be compiler-specific. But then why have them in a dlang subdirectory and not simply in each package's own subdirectory in includes root? Files in /usr/includes/libarcomage are probably easier to find than those in /usr/includes/dlang/libarcomage.

Am Tue, 18 Nov 2014 17:10:18 +0000
schrieb "GreatEmerald" <pastas4@gmail.com>:

> On Tuesday, 18 November 2014 at 16:26:58 UTC, Marco Leise wrote:
> > ABI differences in source files only apply to druntime/Phobos and these imports are generally on the default import path. I was more concerned with GtkD and similar 3rd party libraries, for which you have to specify the import path.
> 
> Fair enough, include files shouldn't be compiler-specific. But then why have them in a dlang subdirectory and not simply in each package's own subdirectory in includes root? Files in /usr/includes/libarcomage are probably easier to find than those in /usr/includes/dlang/libarcomage.

I don't know. I guess maybe because /usr/include typically contains .h files or to avoid directory name conflicts with existing C libraries. I guess we could drop it if we agreed on that.

-- 
Marco