<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 4/4/24 08:52, Eli Zaretskii wrote:<br>
</div>
<blockquote type="cite" cite="mid:86zfu973b1.fsf@gnu.org">
<pre><blockquote type="cite" style="color: #007cff;"><blockquote
type="cite" style="color: #007cff;"><pre class="moz-quote-pre"
wrap="">To me, this means that the two-line example you've shown is processed
in a predictable way, by only using the first one if both match,
whereas a wildcard rule will cause unpredictable results, because the
order in which files are compared against a wildcard is undefined.
Right?
</pre></blockquote><pre class="moz-quote-pre" wrap="">No, rules that use wildcards are still processed in a predictable way. If we set the following two rules (and in that order!):
set substitute-path /foo/include /path/to/foo
set substitute-path /*/include /path/to/somewhere
Then any file names matching '/foo/include' would be rewritten to '/path/to/foo' and NOT '/path/to/somewhere'. Even though any file name matching '/foo/include' would of course also match '/*/include'. The rule selection is entirely based on the order of their definition.
</pre></blockquote><pre class="moz-quote-pre" wrap="">That's not what I meant. I meant that a rule like
set substitute-path /*/include /path/to/somewhere
can catch any parent directory of 'include', and which one it will
catch is not known in advance.</pre></pre>
</blockquote>
<p>This was something I was also wondering about. taking from the
original example:</p>
<p>Max> <span style="white-space: pre-wrap">In the case of conan (<a
class="moz-txt-link-freetext" href="https://conan.io/">https://conan.io/</a>) the path will consist of some constant part and some directory named with some hash value (i.e., <i
class="moz-txt-slash"><span class="moz-txt-tag">/</span>path/to<span
class="moz-txt-tag">/</span></i><unique hash><i
class="moz-txt-slash"><span class="moz-txt-tag">/</span>builddir<span
class="moz-txt-tag">/</span></i>)</span></p>
<p><span style="white-space: pre-wrap">Suppose there are 2 builds for this package, so we have the following valid directories:
/path/to/deadbeef/builddir
/path/to/00000000/builddir</span></p>
<p><span style="white-space: pre-wrap">which of those will be chosen? Is it consistent across gdb runs? OSs? How can a user know in advance which will be picked?
</span></p>
<blockquote type="cite" cite="mid:86zfu973b1.fsf@gnu.org">
<pre><pre class="moz-quote-pre" wrap="">
</pre><blockquote type="cite" style="color: #007cff;"><pre
class="moz-quote-pre" wrap="">Also, in the example I stated in my last reply, no file name that matches '/foo/include' would ever match '/bar/include'. The point I was trying to get across was that two unrelated files can already be mapped onto the same file (accidentally).</pre></blockquote></pre>
</blockquote>
<p>The difference I see is that in the previous examples, the
problem is apparent within what the user would expect (some GDB
script, debug information, or other things related to their
project), whereas with glob matching, the problem may be unrelated
(directory structure of unrelated folders).</p>
<p>If I wasn't aware of this patch, I would never think to check if
the folder structure of my system could be the problem for getting
debug information.<br>
</p>
<blockquote type="cite" cite="mid:86zfu973b1.fsf@gnu.org">
<pre><blockquote type="cite" style="color: #007cff;"><pre
class="moz-quote-pre" wrap="">
</pre></blockquote><pre class="moz-quote-pre" wrap="">Well, two wrongs don't make a right.
I'd be interested to hear opinions of others about this.</pre></pre>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Cheers,
Guinevere Larsen
She/Her/Hers</pre>
</body>
</html>