Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Cc: Simon Marchi <simark@simark.ca>, gdb-patches@sourceware.org
Subject: Re: [RFA] Ensure deterministic result order in gdb.ada/info_auto_lang.exp
Date: Thu, 20 Dec 2018 07:57:00 -0000	[thread overview]
Message-ID: <20181220075728.GC12440@adacore.com> (raw)
In-Reply-To: <1545286359.2974.9.camel@skynet.be>

> Simon/Joel, thanks for the help, I see everyday that I am far to
> master the gdb subtleties :).

Please point me in the direction of someone who knows them all.. ;-)

> On Thu, 2018-12-20 at 00:50 -0500, Simon Marchi wrote:
> > On 2018-12-20 00:29, Joel Brobecker wrote:
> ...
> > > However, if you configure using a relative path to the configure 
> > > script,
> > > things become different. 
> Effectively, I am building and testing out-of-tree, but with a relative
> configure => I will change to use an absolute configure path.

I don't think you have to, and from my perspective, I don't see
why it should be a requirement.

> > Then, I think it makes sense to normalize the paths in order to have a 
> > predictable output, regardless of how gdb was configured, as Philippe 
> > suggested.  Are you also ok with his patch?
> 
> And if ok, do we better do standard_csrcfile_for_ada used for all such
> c files used by gdb.ada, or do we limit the normalization to this test
> ?

I don't have a strong opinion. I don't see a compelling reason to
do the normalization systematically at the moment, as perhaps
it gives us more diverse testing coverage. The cost is indeed
those occasional testcases that fail for some but not others.
I don't know if we expect this to happen so often that we need
to make it systematic.

I would personally start with your patch, and adjust later, if it turns
out we have enough testcases facing that issue.

And for the avoidance of doubt, and not hold the patch waiting for me,
your patch looks good to me.

-- 
Joel


  reply	other threads:[~2018-12-20  7:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-01 13:38 Philippe Waroquiers
2018-12-18 20:32 ` PING " Philippe Waroquiers
2018-12-19  4:31 ` Simon Marchi
2018-12-19 21:36   ` Philippe Waroquiers
2018-12-20  5:31     ` Joel Brobecker
2018-12-20  5:50       ` Simon Marchi
2018-12-20  6:12         ` Philippe Waroquiers
2018-12-20  7:57           ` Joel Brobecker [this message]
2018-12-20 21:14             ` Philippe Waroquiers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181220075728.GC12440@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=philippe.waroquiers@skynet.be \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox