From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8FovOli42V8HHwAAWB0awg (envelope-from ) for ; Wed, 16 Dec 2020 02:33:44 -0500 Received: by simark.ca (Postfix, from userid 112) id E79741F0AA; Wed, 16 Dec 2020 02:33:44 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 3F3C41F071 for ; Wed, 16 Dec 2020 02:33:43 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 463C0384A018; Wed, 16 Dec 2020 07:33:42 +0000 (GMT) Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTP id DD0843857022 for ; Wed, 16 Dec 2020 07:33:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DD0843857022 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8D4EB1168C4; Wed, 16 Dec 2020 02:33:39 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at gnat.com 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 vOD0ZmsU5IPi; Wed, 16 Dec 2020 02:33:39 -0500 (EST) Received: from float.home (localhost.localdomain [127.0.0.1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id C5AC71168A2; Wed, 16 Dec 2020 02:33:38 -0500 (EST) Received: by float.home (Postfix, from userid 1000) id D745CA1916; Wed, 16 Dec 2020 11:33:33 +0400 (+04) Date: Wed, 16 Dec 2020 11:33:33 +0400 From: Joel Brobecker To: Simon Marchi Subject: Re: [PATCH v2] Enable GDB build with in-tree GMP and MPFR Message-ID: <20201216073333.GA934694@adacore.com> References: <71f5437f-c4f5-b58d-06f7-67a4d0b31007@simark.ca> <214e9564-5dfd-65a2-c2d8-6e8398ebc913@simark.ca> <87o8iw9ilx.fsf@tromey.com> <20201215023315.GK3461@adacore.com> <4ea7575a-b727-d9b7-e510-5c8b942f77f9@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ea7575a-b727-d9b7-e510-5c8b942f77f9@polymtl.ca> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pedro Alves , Bernd Edlinger , Simon Marchi , Tom Tromey , "gdb-patches@sourceware.org" Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Simon, > > Here's a radical question: Do we really need to stay in sync with GCC, > > at this point? What are the benefits and requirements of doing so? > > Because GCC doesn't coordinate with us when they make changes to > > the toplevel configury, we're only going to get into these problems > > more. > > Indeed, it's a bit annoying that the burden of syncing is only on one > side. > > What are the original reasons for staying in sync with gcc? I don't know. It was like that when I first joined the project 20 years ago. I assumed it was convenient in the CVS days to have everything under the same "roof", especially for those who want to rebuild the works, knowing that CVS allowed partial checkouts for those who diddn't. > Instead of manually syncing files, I know Pedro already mentioned the > idea of having a single repo with binutils + gcc + gdb, a bit like > LLVM have moved to a big mono repo. Especially with gcc being a C++ > program as well, we want to share more. So desyncing from gcc would > make such a move more difficult. But it's just an idea at this point, > so maybe it's not that important. It'd be interesting in knowing more about what it is that we would be sharing. GCC is absolutely huge (4.5GB), and GDB isn't bad either (1.2GB). Both GCC and GDB move very fast, so reuniting them would be causing a large burden both ways for everyone. If we do, I feel it has to be for strong reasons. > Otherwise, just for convenience reasons, it would be nice to think more > of gcc + binutils + gdb (an maybe others) as a single toolchain, and > having consistency and no suprises in how you build them is a good thing > for those build and integrate them. It would be nice, but is that a sufficiently strong reason to break with the past? > > In fact, how much does the toplevel configure really need to do? > > Intuitively, it doesn't really need to do very much, if we ignore > > all the stuff that's GCC-specific. > > I know next to nothing about the top-level configure, because I never > needed to dig into it. > > > A more relevant conundrum, for me, might be to look at keeping > > binutils and GDB in sync in terms of the options being used. > > > > And then we have the question of how to provide users who want to > > configure parts or all of binutils-gdb what options they can use, > > and what they do. I don't know how easy we can do that via the > > toplevel configure's --help. One interesting question is: Would > > doing so help us avoid inconsistencies with binutils? > > I'm not sure I understand. Do you mean, how do users get to learn about > the configure switches of all projects? > > All I know is that you can do "./configure --help=recursive" from the > top-level, but that's not particularly convenient, it just dumps all > the helps from all the configure scripts. It's good if you want to > find / grep. I didn't know that! This answers my question. To recap where I am on this discussion: First, I need to be honest and upfront in saying that I can't seem to be able to summon the energy to motivate myself towards discussing reunification or even just making GCC and binutils-gdb more consistent in the naming of the configure options. In fact, pending more info, I would still prefer we break the minimal tie we have left in terms of synchronization with GCC, and use that to help ourselves simplify and clarify, without breaking the existing option. In the meantime, if the group decides after discussion that the name of the configure options in GDB for GMP are wrong, and must be changed to follow GCC's lead, then so be it, I will change it. It'll be a bit of a heartbreaker for me because: - It breaks consistency with the way we have been handling dependencies in GDB; - We won't be able to use this nice macro to implement those options, and will end up hand-writing them the same way toplevel configure does (it seems like a lot of code, although I would hope I can do this better and shorter). Note that no one has complained about MPFR in the years we've had it... -- Joel