On 2017-04-11 02:47, Jonathan M Davis via Digitalmars-d wrote:

> Honestly, I don't see how it really makes much sense to use shared libraries
> with D except in cases where you have no choice. The lack of ABI
> compatibility makes them almost useless.
>
> Also, what are we even looking to distribute in debian? I would have thought
> that the normal thing to do would be to build with dub, in which case,
> having the compiler and dub be debian packages makes sense but not really
> anything else. If you're looking to package an application that was written
> in D, then that becomes another question, but then if you just statically
> link it, the ABI compatibility problem goes away as does any need to package
> any D library dependencies.

I agree, I don't see any point in distributing libraries. just applications. But I do know some people will refuse to install anything that doesn't come through the system package manager.

-- 
/Jacob Carlborg

On 2017-04-11 02:20, Walter Bright wrote:
> On 4/10/2017 4:43 PM, David Nadlinger wrote:
>> [1] In fact, it looks like – for example with DMD moving to
>> libunwind-based EH
>> as well – the issue is slowly resolving itself anyway and at some
>> point we'll
>> merely have to sit down for a week and iron out the last few kinks.
>
> dmd is not moving to a libunwind-based EH, it already has moved to it!
>
> But as an example of ABI change, the latest EH @nogc proposal changes
> the layout of the Throwable object, and adds some code to the
> _d_throwdwarf() function.
>
> https://github.com/dlang/druntime/pull/1804

It is possible to solve. For example, in Objective-C they have a non-fragile ABI where you can freely add instance variables to base classes and the offset will be adjusted automatically at load time for the subclasses [1]. The methods are already handled with dynamic message dispatch.

[1] http://www.sealiesoftware.com/blog/archive/2009/01/27/objc_explain_Non-fragile_ivars.html

-- 
/Jacob Carlborg

On Tuesday, 11 April 2017 at 13:43:38 UTC, Jacob Carlborg wrote:
> On 2017-04-11 02:47, Jonathan M Davis via Digitalmars-d wrote:
>
>> Honestly, I don't see how it really makes much sense to use shared libraries
>> with D except in cases where you have no choice. The lack of ABI
>> compatibility makes them almost useless.
>>
>> Also, what are we even looking to distribute in debian? I would have thought
>> that the normal thing to do would be to build with dub, in which case,
>> having the compiler and dub be debian packages makes sense but not really
>> anything else. If you're looking to package an application that was written
>> in D, then that becomes another question, but then if you just statically
>> link it, the ABI compatibility problem goes away as does any need to package
>> any D library dependencies.
>
> I agree, I don't see any point in distributing libraries. just applications. But I do know some people will refuse to install anything that doesn't come through the system package manager.

Every single bit of software that is available in the distribution needs to be packaged in it so you can replicate its build using only what is available in the distro. Fetching things from the internet is not allowed.
(That's actually a hard no in the policy, while other things like the use of static linking are rather "you shouldn't do it if you can avoid it")

The fundamental thing a distribution does is integrating software and creating a consistent whole out of many moving parts. In order to do that, you absolutely can not rely on site-specific package managers like pip, dub, npm, etc. as they are not built for that purpose and only see their own ecosystem.
You could still build with them though in case they integrate well with the distro.

On 2017-04-11 14:56, Jonathan M Davis via Digitalmars-d wrote:

> That's basically what's required with D. It is not ABI compatible across
> releases, and while ABI compatibility might be nice, it really isn't
> reasonable with D - especially with how attributes work and how template
> heavy D code is. If the D compiler gets upgraded, then anything that gets
> built needs everything that it depends on to have been built with that exact
> compiler version.
>
> But if we just use dub - which _is_ the official packaging and build tool -
> then we avoid these issues. Ideally, the compiler and dub would be part of
> the distro, but libraries don't need to be. And it sounds like that's
> basically how the Go and Rust folks want to function as well. So, it would
> make sense for these languages to simply not have their libraries be
> included in distros. The build tools are plenty.

I agree, but I think that they want to avoid having packages that require dependencies outside of the Debian tree to build. That is, a user end application written in D, that is built using Dub. To solve that and still use Dub they would need to package the dependent libraries as source packages and somehow point Dub to the library in the Debian tree and not code.dlang.org. I don't see why that wouldn't be possible and if anything needs to be changed in Dub for that, I think that's reasonable.

-- 
/Jacob Carlborg

On 11/04/2017 3:01 PM, Jacob Carlborg wrote:
> On 2017-04-11 14:56, Jonathan M Davis via Digitalmars-d wrote:
>
>> That's basically what's required with D. It is not ABI compatible across
>> releases, and while ABI compatibility might be nice, it really isn't
>> reasonable with D - especially with how attributes work and how template
>> heavy D code is. If the D compiler gets upgraded, then anything that gets
>> built needs everything that it depends on to have been built with that
>> exact
>> compiler version.
>>
>> But if we just use dub - which _is_ the official packaging and build
>> tool -
>> then we avoid these issues. Ideally, the compiler and dub would be
>> part of
>> the distro, but libraries don't need to be. And it sounds like that's
>> basically how the Go and Rust folks want to function as well. So, it
>> would
>> make sense for these languages to simply not have their libraries be
>> included in distros. The build tools are plenty.
>
> I agree, but I think that they want to avoid having packages that
> require dependencies outside of the Debian tree to build. That is, a
> user end application written in D, that is built using Dub. To solve
> that and still use Dub they would need to package the dependent
> libraries as source packages and somehow point Dub to the library in the
> Debian tree and not code.dlang.org. I don't see why that wouldn't be
> possible and if anything needs to be changed in Dub for that, I think
> that's reasonable.

/usr/share/source/D/package-name-version

Add a search path like that to Dub and create source only library packages and that is pretty much all the distribution we need for libraries I reckon.

Destroy!

On Tuesday, 11 April 2017 at 14:04:44 UTC, rikki cattermole wrote:
> [...]
> /usr/share/source/D/package-name-version
>
> Add a search path like that to Dub and create source only library packages and that is pretty much all the distribution we need for libraries I reckon.

It's more likely that the path would be `/usr/include/d` because that's the place the D sources seem to usually reside, especially if they are also used as "headers" for shared libraries.

At time I am playing around with the idea of using pkg-config[1] files to enlist the sources a D library consists of.
By doing that, we would have a very build-system agnostic way of doing storing that information that can be used by Automake (native), Dub, Meson and even plain Makefiles. It's also very widely used (although it is commonly not used to list sources).

This would also jive really well with the existing D packages in Debian and we could - if we go down the source-only route - still decide to precompile a few selected libraries, for example in case they are very time consuming to compile or really large.

This will *not* solve the issues with Phobos breakage though, as Phobos is a shared library. But doing that would pretty much work around all other problems, except for the cost of having statically linked binaries, but that seems to be inevitable anyway given the state of things.

(Disclaimer: This is not a D team policy draft yet, just an opinion at the moment that might be refined or changed entirely)

[1]: https://www.freedesktop.org/wiki/Software/pkg-config/

On 11/04/2017 3:21 PM, Matthias Klumpp wrote:
> On Tuesday, 11 April 2017 at 14:04:44 UTC, rikki cattermole wrote:
>> [...]
>> /usr/share/source/D/package-name-version
>>
>> Add a search path like that to Dub and create source only library
>> packages and that is pretty much all the distribution we need for
>> libraries I reckon.
>
> It's more likely that the path would be `/usr/include/d` because that's
> the place the D sources seem to usually reside, especially if they are
> also used as "headers" for shared libraries.
>
> At time I am playing around with the idea of using pkg-config[1] files
> to enlist the sources a D library consists of.
> By doing that, we would have a very build-system agnostic way of doing
> storing that information that can be used by Automake (native), Dub,
> Meson and even plain Makefiles. It's also very widely used (although it
> is commonly not used to list sources).
>
> This would also jive really well with the existing D packages in Debian
> and we could - if we go down the source-only route - still decide to
> precompile a few selected libraries, for example in case they are very
> time consuming to compile or really large.
>
> This will *not* solve the issues with Phobos breakage though, as Phobos
> is a shared library. But doing that would pretty much work around all
> other problems, except for the cost of having statically linked
> binaries, but that seems to be inevitable anyway given the state of things.
>
> (Disclaimer: This is not a D team policy draft yet, just an opinion at
> the moment that might be refined or changed entirely)
>
> [1]: https://www.freedesktop.org/wiki/Software/pkg-config/

The problem with /usr/include/d is that is where .di files would be located not .d. This would also match up with the c/c++ usage of it.

On Tuesday, 11 April 2017 at 14:26:37 UTC, rikki cattermole wrote:
> [...]
> The problem with /usr/include/d is that is where .di files would be located not .d. This would also match up with the c/c++ usage of it.

When I asked about this a while back, I was told to just install the sources into the include D as "almost nobody uses .di files except for proprietary libraries" (and do those even exist?).
But in any case, any path would be fine with me as long as people can settle on using it - `/usr/share/d` would be available ^^

On Tuesday, April 11, 2017 14:21:57 Matthias Klumpp via Digitalmars-d wrote:
> This will *not* solve the issues with Phobos breakage though, as Phobos is a shared library.

It could always just be distributed as a static library. There arguably isn't much point in distributing it as a shared library anyway - particularly when it's not ABI compatible across versions. I actively avoid having phobos as a shared library on my systems, because it just causes versioning problems when programs are built against it. All of those problems go away with a static library. And so much of Phobos is templated anyway that there isn't even much to share.

- Jonathan M Davis

On 11/04/2017 3:33 PM, Matthias Klumpp wrote:
> On Tuesday, 11 April 2017 at 14:26:37 UTC, rikki cattermole wrote:
>> [...]
>> The problem with /usr/include/d is that is where .di files would be
>> located not .d. This would also match up with the c/c++ usage of it.
>
> When I asked about this a while back, I was told to just install the
> sources into the include D as "almost nobody uses .di files except for
> proprietary libraries" (and do those even exist?).
> But in any case, any path would be fine with me as long as people can
> settle on using it - `/usr/share/d` would be available ^^

Satoshi is developing one and is having a load of trouble in doing so.
That says everything, we got a lot of work to do.