Hi all,
Changes this weekend:
- New gdc-4.8 branch has been created for stable updates on
D-2.062 and gcc-4.8.x
https://github.com/D-Programming-GDC/GDC/tree/gdc-4.8
- The main development trunk will switch to gcc-4.9 development
(things may get unstable for the next couple of weeks).
Also, everyone welcome Johannes to the team. :-)
Regards
Iain.

Hooray! Welcome Johannes!
That guy rocks my world! :P
Will switching to 4.9 make it harder to support all the 4.8 (and below)
cross compilers out there? Like the console toolchains.
On 23 March 2013 20:33, Iain Buclaw <ibuclaw ubuntu.com> wrote:

Hi all,
Changes this weekend:
- New gdc-4.8 branch has been created for stable updates on D-2.062 and
gcc-4.8.x
https://github.com/D-**Programming-GDC/GDC/tree/gdc-**4.8<https://github.com/D-Programming-GDC/GDC/tree/gdc-4.8>
- The main development trunk will switch to gcc-4.9 development (things
may get unstable for the next couple of weeks).
Also, everyone welcome Johannes to the team. :-)
Regards
Iain.

Hooray! Welcome Johannes!
That guy rocks my world! :P
Will switching to 4.9 make it harder to support all the 4.8
(and below)
cross compilers out there? Like the console toolchains.

The main cross compiler scripts out there only support official
release versions. So it would be recommended to do the same and
stick with gdc-4.8 (or 4.7) branch for the time being. This is
really more of a milestone for me to go off and do the final set
of breaking changes and heavy lifting in gdc code. :o)
Regards
Iain

Hi all,
Changes this weekend:
- New gdc-4.8 branch has been created for stable updates on
D-2.062 and gcc-4.8.x
https://github.com/D-Programming-GDC/GDC/tree/gdc-4.8
- The main development trunk will switch to gcc-4.9 development
(things may get unstable for the next couple of weeks).
Also, everyone welcome Johannes to the team. :-)
Regards
Iain.

Just to be sure, does "for stable updates on
D-2.062 and gcc-4.8.x" also include D-2.063+ (not now but as it
comes out I mean), because you say "stable updates" and I don't
count D as stable. I'm asking because I need to decide on which
branch (master or gdc-4.8) to use for the Archlinux package
(gdc-git) that has to provide the newest git version of gdc, so
if there're going to be improvements or support for new D
versions in the master branch that won't be going into the
gdc-4.8 branch it'd be good to know.
Thanks for your work,
Moritz

Just to be sure, does "for stable updates on
D-2.062 and gcc-4.8.x" also include D-2.063+ (not now but as it comes out

I mean), because you say "stable updates" and I don't count D as stable.
I'm asking because I need to decide on which branch (master or gdc-4.8) to
use for the Archlinux package (gdc-git) that has to provide the newest git
version of gdc, so if there're going to be improvements or support for new
D versions in the master branch that won't be going into the gdc-4.8 branch
it'd be good to know.

Thanks for your work,
Moritz

I'm kinda hoping to push the notion of D front-end minor releases again,
which would include all the latest bugfixes of the current D version, but
any new feature or breaking chances would be omitted. This would be
suitable for gdc because putting on a new release of the front end is too
much hassle as it stands.
Regards
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';

Will switching to 4.9 make it harder to support all the 4.8 (and below) cross
compilers out there? Like the console toolchains.

Also ... how will that affect the ability to compile on Ubuntu using
gcc-snapshot? Working on alpha/beta 13.04 that package has continued to be
updated, but now with feature freeze I imagine it will be left at the version it
currently occupies, which is from the 4.8 development branch.
Without wanting to put any pressure or demands on anyone, I do think it would be
very helpful to D if from now on the latest GDC (read: GDC with latest frontend,
runtime, Phobos) could be guaranteed to build using both the current stable and
development releases of GCC. Are there any particular things that any of us
could do that would help make this easier?
Oh, and ... dare I ask the nasty question, what's the status of GDC becoming
formally integrated into GCC? I can't remember whether this was originally
anticipated as happening with the 4.8 or 4.9 release.

Will switching to 4.9 make it harder to support all the 4.8 (and below)

cross

compilers out there? Like the console toolchains.

Also ... how will that affect the ability to compile on Ubuntu using
gcc-snapshot? Working on alpha/beta 13.04 that package has continued to be
updated, but now with feature freeze I imagine it will be left at the
version it
currently occupies, which is from the 4.8 development branch.

4.8 should be working with that. There haven't been any API-level changes
in GCC in a while...

Without wanting to put any pressure or demands on anyone, I do think it
would be
very helpful to D if from now on the latest GDC (read: GDC with latest
frontend,
runtime, Phobos) could be guaranteed to build using both the current
stable and
development releases of GCC. Are there any particular things that any of
us
could do that would help make this easier?

This is why there are gdc-4.7, gdc-4.8 branches. They are there to be
guaranteed to work with those gcc releases. There won't be any support for
multiple gcc versions in one source. This was done in the past (supporting
gcc-3.4 -> gcc-4.4, then gcc-4.0 -> gcc-4.6). It was a horrible mess and
caused lots of spaghetti code and macros to work around every single
incompatibility problem.
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';

This is why there are gdc-4.7, gdc-4.8 branches. They are there to be
guaranteed to work with those gcc releases. There won't be any support for
multiple gcc versions in one source.

I think you've misunderstood me (although I don't think I expressed myself well,
so mea culpa). I recognize the existence and purpose of the gcc-4.7 and gcc-4.8
branches and it makes perfect sense to organize things that way. It's just that
some remarks make it seem like new versions of the frontend will only be
guaranteed to work on 4.9.
That seems to me to be unfortunate, although I understand how the difficulties
of adapting new versions of the the frontend to GCC may make it inevitable.
I remember you discussing some work that would help to make it possible to just
pull in new versions of the frontend without any large re-working -- IIRC
replacing some direct calls to the DMD backend with a more generic API that
would be backend-agnostic -- and if there's in any case going to be some period
of instability due to switching to 4.9, I wonder if now might be the moment to
do that work?

This is why there are gdc-4.7, gdc-4.8 branches. They are there to be
guaranteed to work with those gcc releases. There won't be any support

for

multiple gcc versions in one source.

I think you've misunderstood me (although I don't think I expressed myself
well,
so mea culpa). I recognize the existence and purpose of the gcc-4.7 and
gcc-4.8
branches and it makes perfect sense to organize things that way. It's
just that
some remarks make it seem like new versions of the frontend will only be
guaranteed to work on 4.9.

Guaranteed is not the right word, but future releases of the frontend will
be present only on 4.9. Though, people are free to backport to 4.8 or 4.7,
as Johannes has done in the past.
I remember you discussing some work that would help to make it possible to

just
pull in new versions of the frontend without any large re-working -- IIRC
replacing some direct calls to the DMD backend with a more generic API that
would be backend-agnostic -- and if there's in any case going to be some
period
of instability due to switching to 4.9, I wonder if now might be the
moment to
do that work?

See my pulls into DMD for a Target struct in the frontend. It's not
complete, but it's slowly being pushed in.
The only expected instability will come from the planned removal of
typinf.c, toobj.c, todt.c - which are to be replaced by a implementation
that builds GCC trees directly.
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';

Guaranteed is not the right word, but future releases of the frontend
will be present only on 4.9. Though, people are free to backport to
4.8 or 4.7, as Johannes has done in the past.

FYI I'll also try to continue updating the frontend in gdc-4.7 and 4.8.

That's good news! I've been unable to get 4.8 to build in my Debian
system (probably due to some system- or configuration-specific breakages
somewhere... Debian multiarch isn't playing nice with GCC's build
scripts). Having the latest frontend available in gdc-4.7 would be a big
help to me.
T
--
Береги платье снову, а здоровье смолоду.

That's good news! I've been unable to get 4.8 to build in my Debian
system (probably due to some system- or configuration-specific breakages
somewhere... Debian multiarch isn't playing nice with GCC's build
scripts). Having the latest frontend available in gdc-4.7 would be a big
help to me.

You were never able to get the latest to build on top of gcc-snapshot as per my
instructions? :-(
I can repeat them here now if it'd be helpful -- I've been building GDC like
this for a long time now, and never had any issues (bar a couple of makefile
errors that Iain quickly fixed).

That's good news! I've been unable to get 4.8 to build in my
Debian
system (probably due to some system- or configuration-specific
breakages
somewhere... Debian multiarch isn't playing nice with GCC's
build
scripts). Having the latest frontend available in gdc-4.7
would be a big
help to me.

You were never able to get the latest to build on top of
gcc-snapshot as per my
instructions? :-(
I can repeat them here now if it'd be helpful -- I've been
building GDC like
this for a long time now, and never had any issues (bar a
couple of makefile
errors that Iain quickly fixed).