<div dir="ltr">As a general rule, I support moving towards explicit run lines and lit-style tests, but some care has to be taken.  If you examine the common Makefiles, you'll see that there's already a lot of special logic for different platforms and compilers.  It might be hard to maintain that if we go back to explicit run lines.  I'm sure there's a way and I'm happy to help brainstorming ideas for how to do it.<div><br></div><div>As a first idea, maybe we could have something like a REQUIRES line but call it COMPILER-SETTINGS instead.   And you could write something like:</div><div><br></div><div>COMPILER-SETTINGS: pic, dwarf, shared-library</div><div><br></div><div>And that would be responsible for figuring out what compiler options to put depending on the platform and compiler.</div><div><br></div><div>the main challenge with using explicit run lines is going to be figuring out how to write run lines that work across all compilers and platforms.  (Luckily we don't have to care about MSVC, mostly just clang + gcc)</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 17, 2018 at 2:49 PM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Jan 17, 2018, at 2:31 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> I don't think new test authors really need to add CMake any more so than they currently need to understand Make.  Which is to say, not very much.  Most Makefiles are currently 1-2 lines of code that simply does nothing other than include the common Makefile.<br>
><br>
> On the other hand, CMake defines a lot of constructs designed to support portable builds, so actually writing and maintaining that common CMake build file would be much easier.  The existing Makefile-based system already doesn't require you to understand the specific compiler invocations you want.  Here's 3 random Makefiles, which is hopefully representative given that I pulled them completely at random.<br>
><br>
> breakpoint-commands/Makefile:<br>
> LEVEL = ../../../make<br>
> CXX_SOURCES := nested.cpp<br>
> include $(LEVEL)/Makefile.rules<br>
><br>
> functionalities/inferior-assert:<br>
> LEVEL = ../../make<br>
> C_SOURCES := main.c<br>
> include $(LEVEL)/Makefile.rules<br>
><br>
><br>
> types:<br>
> LEVEL = ../make<br>
> # Example:<br>
> #<br>
> # CXX_SOURCES := int.cpp<br>
> include $(LEVEL)/Makefile.rules<br>
><br>
> None of this is particularly interesting.  There are a very few tests that need to do something weird.  I opened 10 other random Makefiles and still didn't find any.  I don't believe it would be hard to support those cases.<br>
><br>
> So now instead of "understand Make" it becomes "understand CMake".  Whic is already a requirement of building LLVM.<br>
<br>
Fair point. I would suggest that I'll try to make LLDB's testsuite build out-of-tree using the existing Makefile system. That should be a generally useful first step. After doing this I will hopefully have a much better understanding of the requirements of the Makefiles and then we can revisit this idea with me actually knowing what I'm talking about :-)<br>
<br>
> If our test suite was lit-based where you actually had to write compiler invocations into the test files, I would feel differently, but that isn't what we have today.  We have something that is almost a direct mapping to using CMake.<br>
<br>
Question: how would you feel about converting the Makefiles to LIT-style .test files with very explicit RUN-lines?<br>
<br>
-- adrian<br>
<br>
</blockquote></div>