Third party build systems: how should we treat OpenD in relationship to Walter's D? #56
-
Hi all, I'm a developer of the Meson buildystem. We have some (although not perfect) support for the D language in Meson with support for gdc, ldc, and dmd, including mixing D and other languages like C and C++. We recently had a request, to add support for OpenD, which we are open to. However, it's not really clear to us what the expected long term relationship between OpenD and WalterD (I'll use this to mean "not OpenD") is. After skimming the blog it seems like currently OpenD is a superset of WalterD, with all major changes from WalterD being integrated into OpenD, and most of the major changes to OpenD being either integrated back into WalterD, or at least being considered for integration. This makes OpenD more-or-less a staging branch for WalterD; but I've also seen a willingness to break compat with WalterD if there was a compelling reason. So rather than guess at what the right thing to do here is (and then create a backwards compat headache when we guess wrong), I thought I'd ask the actual community for their thoughts and input. Cheers |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
I keep an eye on pull requests for upstream (that's what i call it, so i say there's three things: old D, which is pre-fork, then upstream d and opend which are the post fork roads) and yeah do pull ones that look useful to me and are easy to merge, but that hasn't been everything. And I know there's some people upstream who keep eyes on us too, but to my knowledge, they've not actually merged anything directly. Still, OpenD is generally a conservative fork. I maintain about a half million lines of D code, so there's a strong self-interest incentive to keep a strong, stable core. Upstream has historically been more willing to break things (my big criticism is they break things without clear direction so it feels pointless, whereas if opend changes something, it is part of a net improvement). I haven't really even put much consideration into the command line interface of the compiler drivers, but again, I don't want to break my existing build habits, so that same self-interested incentive to keep it pretty stable. I don't expect your build system breaking unless you use specific output (like mentioned there, we changed the identification scheme to "OpenD" and a build date instead of a version number), or maybe some obscure preview flag. But generally speaking you shouldn't have much trouble assuming it is just a slightly different version of the same compilers for the same language. |
Beta Was this translation helpful? Give feedback.
I keep an eye on pull requests for upstream (that's what i call it, so i say there's three things: old D, which is pre-fork, then upstream d and opend which are the post fork roads) and yeah do pull ones that look useful to me and are easy to merge, but that hasn't been everything. And I know there's some people upstream who keep eyes on us too, but to my knowledge, they've not actually merged anything directly.
Still, OpenD is generally a conservative fork. I maintain about a half million lines of D code, so there's a strong self-interest incentive to keep a strong, stable core. Upstream has historically been more willing to break things (my big criticism is they break things without cle…