From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 25F673854148 for ; Mon, 31 Oct 2022 12:57:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25F673854148 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 57BBF1E0CB; Mon, 31 Oct 2022 08:57:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1667221022; bh=FgNIWpmBZcvdaOFF8N5Q2AD9bKGIni+Hxo8OnJtyXu8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=t2HqApZvlYOryTsbwNLE0f1H5SvO9u9aHeZVlr/CLSV1jyZEgJZSeUPmfnM0wKBt5 o4wJdBKxqKgtkwkQ1RFiWwaLxp+LcCtU6l79YArKV7ZbFo1FuRDXlPLeoWAgXrTBmz lpSuEXkpp6KYWvzY+z6xCP1WIAEX2RxfldTlxlqU= Message-ID: <34e35222-43f8-058c-ead0-6baa4823cee4@simark.ca> Date: Mon, 31 Oct 2022 08:57:00 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [OB PATCH] gdb/testsuite: Wrap `param_integer_error' in gdb.guile/scm-parameter.exp Content-Language: en-US To: "Maciej W. Rozycki" Cc: Tom de Vries , Simon Marchi , gdb-patches@sourceware.org References: <20221024164338.1762303-1-simon.marchi@efficios.com> <8ef2b43b-9ac4-3a50-3c93-753c8dcfe001@simark.ca> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/29/22 09:56, Maciej W. Rozycki wrote: > Wrap an overlong line in the definition of `param_integer_error' in > gdb.guile/scm-parameter.exp. No functional change. > --- > On Wed, 26 Oct 2022, Simon Marchi wrote: > >>>>>   FTR I'm still looking into it and like you I have hesitated to just paper >>>>> the issue over by allowing both outputs without first understanding what >>>>> is really going on here.  I cannot rule out a distribution-specific patch >>>>> causing a discrepancy here, but I feel like tracking it down. >>>>> >>>>>   NB guile 2.0.13 here, reporting as: >>>>> >>>>> guile (GNU Guile) 2.0.13 >>>>> Packaged by Debian (2.0.13-deb+1-5.4) >>>> >>>> According to that version number, it looks like Ubuntu 20.04? >>>> >>>>    https://packages.ubuntu.com/focal/guile-2.0 >>>> >>>> I tried building on Ubuntu 20.04 against guile-2.0, and I see the same >>>> result as you.  And when I try guile2.0 on Arch Linux (this package >>>> [1]), I also see the same result as you.  So I must have tested it wrong >>>> previously. >>>> >>>> You can dig further if you want, but I'd be fine just accepting both >>>> outputs and saying that guile-2.0 outputs the additional ERROR: while >>>> subsequent versions do not. >>>> >>> >>> FWIW, I did the same here in commit 6bbe1a929c6 ("[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp with guile 3.0"). >> >> Thanks, then I just went ahead and pushed this: > > Thanks, though why such a rush to fix a benign test failure while the > review took months in the first place? The fix seemed relatively obvious, given we already had one instance of this. > FWIW I have been struggling to get multiple versions of Guile compiled > and installed locally (easier) and then GDB built against each of them > (tougher). As it turns out our documentation is misleading. We have: > > `--with-guile[=GUILE]' > Build GDB with GNU Guile scripting support. (Done by default if > libguile is present and found at configure time.) If your host > does not have Guile installed, you can find it at > `https://www.gnu.org/software/guile/'. The optional argument > GUILE can be a version number, which will cause `configure' to > try to use that version of Guile; or the file name of a > `pkg-config' executable, which will be queried to find the > information needed to compile and link against Guile. > > (and similarly in `./configure --help'), so one could have thought > `--with-guile=2.0' will work. Well, not. You need to specify both the > name and the version, e.g.: `--with-guile=guile-2.0', which I find kind of > awkward: why would one want to have a Guile package under a name that is > not "guile"? I think documentation is sensible and it's implementation > that ought to be fixed. Ack. > > But that is not enough. Still I got: > > checking whether to use guile... guile-2.0 > checking for pkg-config... /usr/bin/pkg-config > checking for usable guile from /usr/bin/pkg-config... checking for scm_set_automatic_finalization_enabled... no > configure: error: in `.../gdb': > configure: error: linking guile version guile-2.0 test program failed > See `config.log' for more details > make[1]: *** [Makefile:12496: configure-gdb] Error 1 > > This is because I have built local Guile as static libraries only and > dependencies are not pulled with the (incorrect) `pkg-config' invocation > we have in our configury. > > I got these issues sorted now and will be posting fixes soon. With these > in place I have figured out that the message changed between Guile 2.0 and > 2.2. Thanks. > Last but not least here's a fix I committed as obvious to correct an > overlong line you have introduced with your change. While we do have an > exemption for TCL code, there's no need to make use of it here and these > long lines hit clarity of code badly. I have verified this test case to > still pass after my change. This is subjective. For expected output patterns, I prefer to format it as one expected line per source line. But how you formatted it is fine with me as well. Simon