<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 15, 2014 at 12:30 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Wed, Jan 15, 2014 at 1:37 AM, Kim Gräsman <span dir="ltr"><<a href="mailto:kim.grasman@gmail.com" target="_blank">kim.grasman@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, Jan 14, 2014 at 11:25 PM, Sean Silva <<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>> wrote:<br>


><br>
> I don't think anyone would be against adding a callback to PPCallbacks to<br>
> indicate what the error message is so you can get the data. However, being<br>
> able to affect the outcome of compilation from a PPCallbacks callback seems<br>
> unwise;<br>
<br>
</div>Yes, I agree that decision does not belong in PPCallbacks. But it's<br>
tempting! :-)<br>
<br>
Actually, now that I think about it, Jacob's scenario is the exact<br>
opposite of mine: he seems to be parsing headers in isolation and I<br>
will always see the private header via its umbrella header.<br>
<br>
For me the #error will never trigger, but that also means I'll never<br>
get a PPCallback for it. I just want to scan for it and use it to<br>
connect the private header name to its umbrella.<br></blockquote><div><br></div></div><div>Just use pp-trace on the lone header and pipe it into a 10-line Python script. (once a #error callback is introduced in PPCallbacks, and it is wired into pp-trace).</div>
</div></div></div></blockquote><div><br></div><div>Do'h, I already said that upthread....</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888">
<div><br></div><div>-- Sean Silva</div></font></span><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For Jacob it triggers all the time, and he doesn't care about it.<br>
Stripping out the #error before attempting to parse could be a<br>
solution.<br>
<br>
But it would sure be nice to be able to lean on Clang's parser.<br>
<div><br>
> For the purpose of simply collecting #error directives from TU's, it seems<br>
> like the simplest thing to do would be to use pp-trace (once there is a<br>
> #error callback in PPCallbacks) driven from a short script. You could even<br>
> do better than trying to extract the header name from the #error message:<br>
> just look for the dominating #ifdef and see where it is defined.<br>
<br>
</div>Good idea, I'll save that for later!<br>
<span><font color="#888888"><br>
- Kim<br>
</font></span></blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>