This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Ensure deterministic result order in gdb.ada/info_auto_lang.exp
> > Since both paths appear already normalized in my case, the test does fails for me and your patch
> > would fix it. I am 99% sure I am fine with your fix, I just want to make sure we are on the same
> > page.
> A mystery to me why paths are already normalized in your build ...
> What compilation command do you see in the gdb.log for some_c.c ?
I think it depends how you configure your build, and where you do
your testing. That's why Simon asked you about it.
Personally, I build and test out-of-tree, and this is the recommended
way. And the second important element is the fact that I use an absolute
path to the configure script:
$ cd /path/to/build
$ /path/to/src/configure [...]
$ make
When you configure GDB that way, then the testsuite framework will
compile the C files by passing the absolute path to those C files.
For instance on example from my gdb.log file:
| Executing on host: gcc [...] -c -g [snip snip] /path/to/src/gdb/testsuite/gdb.base/gdb1090.c (timeout = 300)
However, if you configure using a relative path to the configure script,
things become different. With the same example, but configured using...
$ cd /path/to/build
$ ../src/configure [...]
... the path given by the testsuite frame to GCC in order to compile
C files now includes these relative directory adjustments you are
seeing. Eg:
| Executing on host: gcc [...] -c -g [...] /path/to/bld/gdb/testsuite/../../../../act/gdb-public/gdb/testsuite/gdb.base/gdb1090.c (timeout = 300)
Whether it must be this way or not and why, I don't know. But I don't
think it's even worth exploring the idea of changing it.
--
Joel