The D ecosystem in Debian with free-as-in-freedom DMD

[H. S. Teoh via Digitalmars-d]

On Mon, Apr 10, 2017 at 06:12:26PM +0000, Matthias Klumpp via Digitalmars-d wrote:
> On Monday, 10 April 2017 at 17:29:04 UTC, H. S. Teoh wrote:
> > On Mon, Apr 10, 2017 at 11:40:12AM +0000, Matthias Klumpp via
> > Digitalmars-d wrote: [...]
> > > [...]
> > > If we do that, we will run into the D ABI trap: Libraries compiled
> > > with compiler X can not be used from software compiled with D
> > > compiler Y. There is actually no ABI stability guarantee even
> > > between DMD releases.  This will make integrating D a huge pain.
> > > Recompiling the dependency-chain of a software from source when
> > > compiling a package using the "right" compiler and statically
> > > adding the code is forbidden by distro policy.  Having static
> > > libraries in the dependencies doesn't solve the issue.  Compiling
> > > each library with all D compilers is highly impractical and not
> > > really feasible.
> > 
> > This is not a hard problem to solve, IMO.  Just build the library
> > into two separate binaries, each with a SONAME that encodes the ABI
> > it is compatible with.
> 
> This would require to hack each and every build system to support this
> *and* if there is a pkgconfig file for the shared library, to change
> all depending software to check for multiple library names which is a
> bit crazy...

Hmm.  I guess there's no easy way to make dmd/ldc emit dependencies with
modified SONAMEs?  So yeah, you're right, every software that depends on
said libraries would have to explicitly depend on a different SONAME
depending on what they were built with.  OK, crazy idea, nevermind. :-(


[...]
> > - The only case where I can see we'd want to compile with dmd is if
> >   the target software uses features that are only available on dmd.
> 
> Oddly, it usually is the other way round :P - some projects explicitly
> want LDC or GDC.

Well, if they explicitly want ldc/gdc, then we'll just have to do with
that.  But I think ldc should be able to compile anything that compiles
with gdc, so we might still be able to standardize on ldc by default.


[...]
> > Of course, this in no way diminishes the priority in *distributing*
> > dmd in the Debian archive as -dev packages. Just don't build other
> > Debian packages with it. :-D
> 
> Indeed. It needs license review (urgh... ^^), but when it's through
> that there is no reason not to have it in Debian main and Ubuntu.

One issue, though: if we standardize on compiling Debian packages with
ldc, then what do we do with libraries that are not ABI-compatible with
dmd?  Since users would expect that if they need libfoo, they'd just
`apt-get install libfoo-dev` and then they should be able to just run`
dmd -L-lfoo` and it should all magically "just work".


[...]
> > I'd like to be involved, since I *am* technically a Debian developer
> > (though haven't been very active for the past long while -- I do try
> > to at least keep the meager few packages I maintain up-to-date,
> > though).
> 
> It's unlikely that I will maintain the dmd package (I might
> co-maintain it or sponsor uploads though - reason is simply lack of
> time and -ETOOMANYPROJECTS), so any help there is highly appreciated
> and I'd help with it whenever I can (I just can't make long-term
> commitments).  If DMD is uploaded as part of the D team, spreading the
> maintenance cost will be rather simple too :-)

Yeah, the reason I haven't been very active in Debian is also due to
ENOTIME, so I doubt I'd be able to keep up with maintaining dmd.  But if
it's spread among more D team members, it could be more workable.


T

-- 
Heuristics are bug-ridden by definition. If they didn't have bugs, they'd be algorithms.