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.