[dmd-internals] 1st Biweekly Sprint Planning

Iain Buclaw via dmd-internals dmd-internals at puremagic.com
Thu Jul 9 12:56:59 PDT 2015


On 9 July 2015 at 21:09, Martin Nowak via dmd-internals <
dmd-internals at puremagic.com> wrote:

> On 07/09/2015 03:45 PM, Iain Buclaw wrote:
> > Recently got on-board with Semaphore-CI (better platform than
> > Travis-CI IMO)
>
> Well adding D to the list of supported PLs always helps our visibility,
> but then again there is way more important stuff to do than adding a
> Travis-CI alternative.
> It's also an endless job to add support for all CI systems.
> http://www.slant.co/topics/186/compare/~circleci_vs_shippable_vs_travis
>
> > currently investigating using their docker-beta platform to push out
> binary tarballs
>
> For release building? Are you cross-compiling? That would be interesting
> for dmd as well. VirtualBox doesn't make things faster, but
> cross-compiling comes with it's own drawbacks.
>
>

Building cross-compilers is the end goal, yes.



> > Download paths needs an overhaul.  In retrospect I think it's
> > not a good idea to update D frontend versions in GCC release
> > branches.
>
> Not sure. In the long-run you want to move gdc into the gcc repo, so
> gcc's version numbers should be dominant.
> I think 4.9.2+2.068.0 perfectly makes sense.
> How does gccgo handle this?
>
>
Whatever is the current version of Go when GCC release freezes is the
version that will be shipped with it.

If I imposed this more strictly, we would instead have:

4.8.4+2.064.2
4.9.2+2.065.0
5.1.0+2.066.1
6.0.0+2.067-dev

Yes, DMD releases take so long, they are pretty much in sync with GCC.
(Although, still one release behind DMD by the time I manage to complete
the merge ;-)

Iain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20150709/164b948e/attachment.html>


More information about the dmd-internals mailing list