<div dir="ltr">On Wed, Mar 6, 2013 at 2:17 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Tue, Feb 19, 2013 at 11:08 AM, Edwin Vane <span dir="ltr"><<a href="mailto:edwin.vane@intel.com" target="_blank" class="cremed">edwin.vane@intel.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: revane<br>
Date: Tue Feb 19 13:08:10 2013<br>
New Revision: 175544<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=175544&view=rev" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project?rev=175544&view=rev</a><br>
Log:<br>
Add support for auto-generating LIT tests by the build<br>
<br>
autoconf and CMake flavours both updated to auto-generate files for use<br>
in cpp11-migrate's LIT tests.<br></blockquote><div><br></div></div><div>Sorry I just saw this and didn't comment earlier, but I'm not a huge fan of this.</div><div><br></div><div>First, I think we should be *extremely* judicious in the use of *auto* generated tests. They are often much harder to debug because the test isn't checked in somewhere that folks can see and poke at. Using a script to help generate or update tests with a high degree of repetition, but still keeping the test text checked in directly, is often easier on developers. Clearly, this is subjective. We have to evaluate on a case-by-case basis. But I'd encourage some caution about generating too many tests.</div>

<div><br></div><div>Second (and more immediately), we don't need this in the build system. Tests already have RUN lines, you should just add whatever generator you need to the tools lit knows about, and generate the inputs in your RUN lines. This also makes it easier to evaluate for each test whether generating the input on the fly is really the best option.</div>

<div><br></div><div>I'm going to try to convert everything to follow the second point.</div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra" style>I've pulled out the build system changes and reworked the tests in r176627 to not require generated code at all. Sorry for doing this so abruptly, but the changes to the build system were blocking our integration of clang-tools-extra with our own build systems, and given the concerns about complexity it seemed the right path forward was to just make the jump. It turned out to simplify the whole thing quite a bit IMO. the tests themselves are a bit verbose now, but that can be fixed by teaching the clang tools to accept a source file on stdin and write the transformed file onto stdout. That would be really nice for the entire clang tools test suite. We could even bake in support for stripping comments.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Let me know if you have problems or questions here, I feel bad for just charging forward, but this kept breaking stuff for us.</div></div>