From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35824 invoked by alias); 13 Apr 2016 14:16:59 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 35765 invoked by uid 89); 13 Apr 2016 14:16:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=grace, Hx-languages-length:1859, impending, nicely X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 13 Apr 2016 14:16:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id ED8A9116939; Wed, 13 Apr 2016 10:16:50 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nZOR9Q-xD4Am; Wed, 13 Apr 2016 10:16:50 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 5D698116931; Wed, 13 Apr 2016 10:16:50 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 075C74976A; Wed, 13 Apr 2016 07:16:49 -0700 (PDT) Date: Wed, 13 Apr 2016 14:16:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: Yao Qi , "gdb@sourceware.org" Subject: Re: C++ conversion status update Message-ID: <20160413141648.GI31406@adacore.com> References: <565460FB.6070103@redhat.com> <86zixdnlfg.fsf@gmail.com> <566F13D4.9000900@redhat.com> <570D91F6.2020702@redhat.com> <20160413124127.GG31406@adacore.com> <570E51CB.6010304@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <570E51CB.6010304@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-04/txt/msg00011.txt.bz2 > 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