From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 38F0F388E835 for ; Tue, 6 Jul 2021 14:58:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 38F0F388E835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 642BE22734; Tue, 6 Jul 2021 14:58:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1625583509; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PlCTL/Gu4PXvM3xXHeI4ccjsH3Vlt2CiueSDEMhvtF8=; b=AZJ8xEIR3ie/1aDtUB2yDzPustuv3clgn26KPzP78GFDdsr+KnIX2GZW1aDOOwoOdGY36r FucahCK60XltjwdAEbCezoGEhSnyiigc3MSXWcbQM8UXC0WRP1OY+9U+LpCCTPWv6KSiiL ITisgKkxmb0UxDMmypZ93BasLOo0FeQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1625583509; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PlCTL/Gu4PXvM3xXHeI4ccjsH3Vlt2CiueSDEMhvtF8=; b=4Pj/9o5cOHRD5QFDv0HduJWOUth8j+Sokr/FG64XxibQCCYjBbcsQ5I/FEOCFcrGU/z/PN Sb1E24P+z9x3I4AQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 37B6113A8F; Tue, 6 Jul 2021 14:58:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 0aMpDJVv5GDSXQAAMHmgww (envelope-from ); Tue, 06 Jul 2021 14:58:29 +0000 Subject: Re: [ANNOUNCEMENT] GDB 11 release branch created! To: Eli Zaretskii Cc: brobecker@adacore.com, tom@tromey.com, bernd.edlinger@hotmail.de, gdb@sourceware.org References: <87im1q78im.fsf@linux-m68k.org> <78ca1c45-beb3-966f-e995-912bc1e115c1@suse.de> <83h7h9gcu8.fsf@gnu.org> <83czrwhj02.fsf@gnu.org> From: Tom de Vries Message-ID: <8731b5b6-814f-8559-d72e-b8c86e2ee6d7@suse.de> Date: Tue, 6 Jul 2021 16:58:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83czrwhj02.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.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: , X-List-Received-Date: Tue, 06 Jul 2021 14:58:31 -0000 On 7/5/21 5:34 PM, Eli Zaretskii wrote: >> 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). Cool. > But the change isn't so trivial, so I think it isn't > appropriate for the branch. Ack. > 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. > AFAIU, the problem is not that users get a couple of sections in the manual they don't need. The problem is that the users get the incorrect version of a section of the manual. > Could you please see if my proposal solves the immediate problem? And > if not, explain what I missed? > Sure, no problem. I did this: ... - READLINE_TEXI_INCFLAG= + READLINE_TEXI_INCFLAG='-I $(READLINE_DIR)' ... in src/gdb/configure and managed to finish the build. >> 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. > Well, I don't see any reason to delay the release. I'd say the easiest way to fix the problem is to revert the commit that introduced the problem. Thanks, - Tom