This is the mail archive of the
mailing list for the GDB project.
Re: C++ conversion status update
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 13 Apr 2016 07:16:49 -0700
- Subject: Re: C++ conversion status update
- Authentication-results: sourceware.org; auth=none
- References: <565460FB dot 6070103 at redhat dot com> <86zixdnlfg dot fsf at gmail dot com> <566F13D4 dot 9000900 at redhat dot com> <570D91F6 dot 2020702 at redhat dot com> <20160413124127 dot GG31406 at adacore dot com> <570E51CB dot 6010304 at redhat dot 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* | \
> 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!