<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi everyone,<div><br></div><div>[ CMake + TRE ]</div><div>I was able to make CMake use TRE, by changing the RegularExpression.{cxx,hxx.in} files.</div><div><br></div><div>I ran the CMake tests, and 100% pass. See the attached log file. </div><div>(NOTE: Bootstrap, complex, complexOne were initially not aware of TRE dependency, but I fixed that easily).</div><div><br></div><div><br></div><div>[ Impact of using CMake + TRE on our builds ]</div><div>We picked one of our build machines and replaced the ctest binary on it.</div><div>The impact on the build time is pretty dramatic:</div><div> CMake:<span class="Apple-tab-span" style="white-space:pre"> </span>7h39m</div><div> CMake + TRE:<span class="Apple-tab-span" style="white-space:pre"> </span>1h06m </div><div><br></div><div>This is a machine that has two cores.</div><div><br></div><div>On machines that have more cores, the impact is even greater. On my 8 core machine, running a particular build task:</div><div><div> CMake:<span class="Apple-tab-span" style="white-space: pre; "> </span>19m57s</div><div> CMake + TRE:<span class="Apple-tab-span" style="white-space: pre; "> </span> 1m30s </div></div><div><br></div><div><br></div><div>[ Regular expressions syntax ]</div><div>In terms of regular expressions syntax, the only difference that I've seen is that TRE treats the curly brackets "{" and "}" as special characters, because it uses them for its "approximate matching". Details here:</div><div> <a href="http://laurikari.net/tre/documentation/regex-syntax/">http://laurikari.net/tre/documentation/regex-syntax/</a></div><div><br></div><div>The only CMake component that uses curly brackets in a regexp is:</div><div> Modules/FindJNI.cmake</div><div>but it was trivial to fix because they were used as mere delimiters.</div><div><br></div><div>As mentioned earlier, after this change 100% of the tests pass.</div><div><br></div><div><br></div><div>[ Implications ]</div><div>Note that CTast is *not* the only component that would benefit from faster regular expressions.</div><div><br></div><div>I've found at least one other reported case when regular expression were too slow in CMake:</div><div> <a href="http://public.kitware.com/Bug/print_bug_page.php?bug_id=5537">http://public.kitware.com/Bug/print_bug_page.php?bug_id=5537</a></div><div><br></div><div>Since Glob uses RegularExpression, I would not be surprised if CMake+TRE will be faster on large code bases.</div><div><br></div><div><br></div><div>CONCLUSION: </div><div> - TRE is fast, benefits build times immensely</div><div><br></div><div>QUESTION:</div><div> - Does anyone see a problem if we add TRE in CMake the same way as ZLIB, CURL, etc? (i.e. in ./Utilities/) </div><div><br></div><div><br></div><div>sincerely,</div><div>Alex Ciobanu</div><div><br></div><div></div></body></html>