<div dir="ltr">I have a couple of ideas here.  But before I list them I wanted to ask how you guys build LLVM.  LLVM doesn't have a native Xcode build, so presumably you're already running CMake once in order to build LLVM for LLDB to link against.  Can you expand on this workflow a little?  <div>
<br></div><div>Anyway, here's some options.  Maybe there's more, this just what I came up with after a little brainstorming</div><div><br></div><div>1) Building the test suite on MacOSX requires an additional step beyond just building LLDB.  You would have to build the test programs first, presumably the same way that you build LLVM assuming you use the CMake llvm build, then the test script would find the already-built test programs.  Note that this is the same as what non MacOSX people would do, except that for us it wouldn't be an extra step, simply typing "ninja check-lldb" would automatically do everything, since building the test programs would be a dependency of running the test suite.</div>
<div><br></div><div>2) Have parallel builds for the test programs on MacOSX and other platforms.  MacOSX build would remain as-is, and other platforms would use CMake to build the tests.  Maybe there could be an option in the test script to force MAKE-mode for backwards compatibility.  This isn't that different from the current situation, since MacOSX and other platforms already have parallel build systems for LLDB itself.  The biggest difference is that now when adding new tests, you would have to add both a CMake file and a Makefile.  This is a small annoyance, but looking at the makefiles, they are all pretty simple and most of the logic is factored into the top-level Makefile.  I think the same could be done for the CMake, so that new CMake files are a few lines.</div>
<div><br></div><div>3) Have MacOSX not use the native Xcode build anymore.  This goes back to my original question though, about what the workflow is like.  I imagine it's probably just historical, but why doesn't LLDB use the CMake build already?  CMake can already generate Xcode projects, what are the differences between the Xcode projects generated by CMake versus the hand-maintained Xcode projects.  Assuming they're significant enough to warrant serious concerns about the usability of a CMake-generated Xcode project, I wonder if it's something that's fixable to the point that using a CMake-generated Xcode project is almost the same as using the hand-maintained Xcode project.  I've never used Xcode before, so I'm a bit clueless here.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 18, 2014 at 6:20 PM,  <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That won't work on the Mac for Xcode builds, which is what pretty much all of us here use to build lldb.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Jul 18, 2014, at 6:03 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
><br>
> I don't think it's that simple, because some of the test have to exercise features of the debugger that deal with how your program was built.  Was it built with symbols, without symbols, with FPO, are the symbols in a different folder than the exe (e.g. testing the symbol search path), etc.<br>

><br>
> I thought about it a little, because I agree with you that it's annoying to have the test run CMake and then depend on some external build tool, but I think an elegant way to make this work is to just have all of the test executables and libraries built at the same time you build LLDB.  The nice thing about this is that the tests end up running significantly faster, because simply running the test suite will never end up building anything, it will just load executables that have already been built.  It also avoids the additional dependency problem, because you're already building LLDB with CMake to begin with.<br>

><br>
><br>
> On Fri, Jul 18, 2014 at 5:24 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
> I haven't stared deeply at LLDB's usage of make, but I think adding CMake to the mix is a step in the wrong direction.  CMake isn't a make replacement, it's a meta-build system and autoconf replacement.  Once you generate build files, you'll still have an external dependency on some other build system (ninja or msbuild).<br>

><br>
> Aren't most LLDB test programs simple enough to be linked with something like the lit shell interpreter?<br>
><br>
><br>
> On Fri, Jul 18, 2014 at 3:55 PM, <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br>
> This is mostly historical.  So long as I don't have to do it, I don't really mind one way or the other.  OTOH, beware, this sort of thing is sticky...<br>
><br>
> Jim<br>
><br>
><br>
> > On Jul 18, 2014, at 3:47 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
> ><br>
> > I'm not very well versed in MAKE, but an issue I'm encountering currently is the use of MAKE in compiling the test files.  Is there any reason CMake can't be used here?  There's a lot of shell-specific logic in the Makefile currently that is hard to reproduce on Windows, so if we can port everything to CMake it might be helpful.<br>

> ><br>
> > Thoughts?<br>
> > _______________________________________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>