<div dir="ltr"><div dir="ltr">Hi,<br><div><br><div class="gmail_quote"><div dir="ltr">On Sun, Sep 30, 2018 at 5:20 AM Luke Benes <<a href="mailto:lukebenes@hotmail.com">lukebenes@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maarten,<br>
Thanks for your suggestion here and your earlier contributions to the Cppcheck Report. I agree that we should create the include file dynamically. However the approach used by your script seems like overkill. Cppcheck already finds that quoted includes like<br>
#include "GraphicExportFilter.hxx"<br>
.<br>
Also when there seems to have been a coding style that all <> includes outside of /inc folders should be defined by their relative path. Cppcheck only complains about 4 missing includes that do not follow this pattern.(see my earlier email on oddball includes).<br>
<br>
Unless, I'm missing something, I still prefer this approach:<br>
$ find . -type d \( -name "inc" -o -name "include" \) |sort > inc.txt<br>
<br>
inc.txt only has ~200 entries, where as  /tmp/tmpfile.txt has ~1,800 after sorting it.<br>
<br>
-Luke<br>
<br></blockquote><div><br></div><div><br></div><div>I was about to speak of the supposedly preferred approach that I took, for the reasons that my approach :<br></div><div><br></div><div><br>1.) Does not depend on the existence of and/or adherence to any customs/practices/coding styles, which can and do change over time, or are simply overlooked, causing errors that people will have to correct manually or even cause silent failure that no-one notices.<br>2.) Is fully dynamic, and does not have any paths 'hard-coded' into the script, which one would have to adjust if in the future the paths/names change. I already am worried about the fact that the approach uses hard-coded defines (-DFOO/-UBAR) on the commandline instead of determining them dynamically, but I currently see no way to do this differently, so I guess that has to stay for now. Also, I guess the chance that these defines change over time is far less likely than the chance that directory names and locations change.<br><br><br>But then I decided to put my money where my mouth is, and made the necessary changes to the cppcheck-report script, and guess what ? Apart from approach differences, your version completed in an acceptable execution time, whereas my approach took *ages* (after 40 minutes cppcheck was still only about 1% completed, after which I aborted the attempt).<br><br><br>As of now, I cannot tell what causes this massive difference in execution time, but the only visible difference in cppcheck output was this :<br><br><br>my version: Checking basctl/source/basicide/basides1.cxx: LINUX=1;__GNUC__=1;UNX=1;NDEBUG=1;CORE_LITTLE_ENDIAN=1;__LITTLE_ENDIAN__=1;__x86_64__=1;LINUX=1;__GNUC__=1;UNX=1;NDEBUG=1;CORE_LITTLE_ENDIAN=1;__LITTLE_ENDIAN__=1;__x86_64__=1...<br>your version: Checking basctl/source/basicide/basides1.cxx ...<br><br>Obvious things: 'my version' listed the -D in the output, your's did not. 'My version' lists the defines *twice* (which can't be good).<br></div><div><br></div><div>I don't know what's going on here.<br></div><div><br>- Maarten<br></div><div><br></div><div> </div></div></div></div></div>