Re: C++ conversion status update

[Joel Brobecker <brobecker@adacore.com>]

> OK.  We can just add an entry to lynxos to GDB_AC_BUILD_WITH_CXX
> to make it default to C, still.  Like this, against
> the version in the users/palves/cxx-conversion branch:
> 
> diff --git i/gdb/build-with-cxx.m4 w/gdb/build-with-cxx.m4
> index aa3661f..e42719e 100644
> --- i/gdb/build-with-cxx.m4
> +++ w/gdb/build-with-cxx.m4
> @@ -30,6 +30,7 @@ AC_DEFUN([GDB_AC_BUILD_WITH_CXX],
>      *-*nto* | \
>      *-*bsd* | \
>      xtensa*-*-linux* | \
> +    *-*-lynxos* | \
>      null)
>        enable_build_with_cxx=no ;;
>      *)
> 
> That'll give you until all the other hosts are confirmed-converted,
> at least.

We could do that indeed; or, IIRC, there is a configure option
to force the use of C instead of C++. I don't mind requiring
the user to force it; it's a good reminder (and ties in nicely
with another comment below).

> > If we do, perhaps it's time to change the major version number
> > to 8.0?
> > 
> 
> Or maybe defer that until we actually declare C mode unsupported.
> I myself hope to do that before the next release, but ...  :-)

:-). I know it sounds self-serving, but I think we should be giving
users a one-release grace period. Make C++ the default, but with
C support for those who can't build with C++. That way, they can
still build, but they are clearly on notice about the impending
change. Then, as soon as the release branch is cut, we can flip
the switch. That way, I don't think you'll have to keep the compat
mode for much longer than you were planning to.

> (Another thought that crossed my mind before is to switch the
> numbering scheme to follow something like gcc's.  That is, make
> the minor number be the major number going forward, as
> the minor number actually counts new-feature releases, while
> the major number is arbitrary.)

Definitely a possibility. Let's discuss that separately at some point!

-- 
Joel