From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SBB9Iqcm42BMYgAAWB0awg (envelope-from ) for ; Mon, 05 Jul 2021 11:35:03 -0400 Received: by simark.ca (Postfix, from userid 112) id 7EB3B1F1F2; Mon, 5 Jul 2021 11:35:03 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 68E781E940 for ; Mon, 5 Jul 2021 11:35:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 727433864C65 for ; Mon, 5 Jul 2021 15:35:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 727433864C65 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1625499301; bh=npRH7fNoNP+SVu/gd+4bjz18CJFpmZHb2x8mt7i4u9Y=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=dRHUctbvT0QtFD6sVyw8VuQEtk2Qa6167ewXO9CfJTKFKhIs4DhVPtaKBavrTd4ch 5h3yTsfKvPJRG/INq1VX9FhAeteGfk6aij2MSGhFVBWkYPyKo5zU5TgWhwZAHr+zEX 1aTCJn/w6a4HCCXw0S1jQGHzqx8yw39QQ66a+JNo= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 7C5DA385781D for ; Mon, 5 Jul 2021 15:34:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7C5DA385781D Received: from fencepost.gnu.org ([2001:470:142:3::e]:41306) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m0QcD-0003dD-F8; Mon, 05 Jul 2021 11:34:33 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2449 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0QcD-00015Q-3I; Mon, 05 Jul 2021 11:34:33 -0400 Date: Mon, 05 Jul 2021 18:34:37 +0300 Message-Id: <83czrwhj02.fsf@gnu.org> To: Tom de Vries In-Reply-To: (message from Tom de Vries on Mon, 5 Jul 2021 15:36:07 +0200) Subject: Re: [ANNOUNCEMENT] GDB 11 release branch created! References: <87im1q78im.fsf@linux-m68k.org> <78ca1c45-beb3-966f-e995-912bc1e115c1@suse.de> <83h7h9gcu8.fsf@gnu.org> X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb Reply-To: Eli Zaretskii Cc: gdb@sourceware.org, tom@tromey.com, bernd.edlinger@hotmail.de, brobecker@adacore.com Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" > Cc: brobecker@adacore.com, tom@tromey.com, bernd.edlinger@hotmail.de, > gdb@sourceware.org > From: Tom de Vries > Date: Mon, 5 Jul 2021 15:36:07 +0200 > > > Wouldn't it be better to modify the configure script so that > > READLINE_TEXI_INCFLAG always includes "-I ${READLINE_DIR}"? Or did I > > misunderstand the reason why makeinfo doesn't find the Readline > > manual? > > I was not trying to suggest a fix, but merely trying to point out that > we seem to be going forth and back on this (that, and the reproducer > seemed to be worth sharing at that point). > > Anyway, by now I've investigated a bit further. > > The difficulty seems to be that the documentation is dependent on > configure options. Yes, and that should probably change (I have an idea for how to do that). But the change isn't so trivial, so I think it isn't appropriate for the branch. Therefore, I tried to propose a band-aid: have the readline/readline/doc directory be _always_ on the makeinfo's include path, so that if someone reconfigures GDB like in the reproducer, they still get a successful build, albeit with a couple of sections in the manual they don't need. Could you please see if my proposal solves the immediate problem? And if not, explain what I missed? > I can think of two clean ways to handle pre-generated docs in such a case: > - not including pre-generated docs in the source tarball That'd contradict GNU conventions: we always include the generated Info manuals in the release tarballs. > - generating a version of the docs for the source > tarball, that conservatively agrees with all configure choices. I think this is sufficiently complex to avoid doing that on the branch. We could try this on master, of course. But right now, I'd like to fix the branch so that we don't have a regression, while still allowing people to build GDB without having Texinfo installed. > To give an example of what I'm concerned about: say a user has a system > without makeinfo, and builds with --with-system-readline. Then the gdb > documentation point to the in-source readline docs, which does not > necessarily agree with the actually used readline version. That's true, but I don't see that as a serious enough problem to delay the release of GDB 11. Of course, it isn't my call, eventually.