Sent from my iPhone
> On Oct 8, 2018, at 8:09 AM, Zachary Turner via llvm-dev > <llvm-...@lists.llvm.org> wrote: > > > >> On Mon, Oct 8, 2018 at 7:42 AM Greg Bedwell <gregbedw...@gmail.com> wrote: >> Thanks for raising this. >> >> This is a topic I've been interested in for a while too, as I've had to do a >> few of those lite.site.cfg fix-ups that you mention (in fact I have one >> sitting unreviewed at https://reviews.llvm.org/D40522 although I've not >> pinged it in a long time so I'll need to double check that it's still an >> issue). There are also other issues. For example >> LLVM_ENABLE_ABI_BREAKING_CHECKS is implemented in such a way that by default >> the value is defined at CMake time based on the value of >> LLVM_ENABLE_ASSERTIONS which gets confusing with the Visual Studio generator >> where the value of LLVM_ENABLE_ASSERTIONS does not necessarily correspond to >> whether assertions are enabled or not. >> >> As I understand it, what you're proposing is to not support building for any >> configs that return true for GENERATOR_IS_MULTI_CONFIG. This includes all >> of the Visual Studio generators, but also the Xcode generator. I'm not an >> Xcode user. Does anyone make use of that generator or is it entirely >> replaced in practice by single-config generators, i.e. Ninja? > I haven't heard of anyone using the Xcode generated project. I’ve been using the Xcode generated project on a daily basis for several years. > In fact, LLDB maintains its own hand-created Xcode project precisely because > the CMake one is considered "unusable". I don’t know where this “unusable” comment came from. My impression is that nobody really tried the generated Xcode project: LLDB had its own hand-maintained Xcode project for a long time, and the CMake build system came later. Workflows didn’t necessarily change when they could have. > That said, I don't personally use Xcode or a Mac, so I can't speak for if > anyone else might be using the Xcode generator. There are certainly other users. The Swift Compiler’s build script explicitly supports setting up a usable Xcode project because we recommend it for a decent build/debut experience in the Mac. I am strongly against removing support for building within Xcode, because it is my primary development workflow and having a skeleton project + make would be a huge regression. - Doug > >> >> We're still using the Visual Studio generators in production at Sony at the >> moment. This is largely because until recently they were actually faster >> than Ninja for us due to the availability of distributed builds on our >> network. We've recently patched in support for our system into our private >> branch of Ninja now so in theory it should be faster/on-par again but we've >> not yet pulled the trigger on making them the default. If there's consensus >> that this is the way forward, then we'll definitely need some time to make >> the change internally. I'm only speaking personally in this reply as I'll >> need to discuss with the rest of the team before we can reach a position, >> but basically I wouldn't want the conclusion of this thread to be "No >> dissenting voices, so here's an immediate patch to remove support!" > There's a patch up right now to add support for /MP. > https://reviews.llvm.org/D52193. In theory this should also help unless you > have your own distributed build system. I'm curious what was actually faster > though. I've found hitting Ctrl+Shift+B from within Visual Studio to be much > slower, but it seems like a lot of that time is going to MSBuild resolving > dependencies and stuff. Like it sometimes takes over 30 seconds before it > even starts doing *anything*. > >> >> I've not tried the workflow you describe. I'll try it out in the coming >> days to see how it works for me. My main concerns are: >> >> * How far will it raise the barrier of entry to new developers? My >> impression is that a lot of students coming to LLVM for the first time, >> first build out of the box with Visual Studio before later discovering this >> magical thing called Ninja that will speed things up. Potentially this >> could be mitigated with good enough documentation in the getting started >> guide I expect. > There's a couple of ways we can mitigate this. We can print a warning when > using the VS generator, and we can update the getting started guide. But I'm > not sure it will raise the barrier of entry much, if at all. Right now new > developers are struggling with building and running even with VS. Every > couple of weeks there's posts about how the test suite wouldn't run, or > something is running out of heap space, or they forgot to use -Thost=x64. > >> >> * LLVM's CMake is super-slow on Windows, and we'd need to run it twice >> whenever there are project changes. This could be a significant drawback in >> the proposed workflow but I'll need to try it before I can say that for sure. > I mentioned this in my response to Aaron, but just to re-iterate here, you > only ever need to run CMake on the VS project if you actually want to edit a > file that has been added, which is pretty rare. I have gone several months > without re-generating and it works fine. This is actually a big improvement > over the VS-generator-only workflow. FWIW, my experience is that the Ninja > generator is at least twice as fast as the CMake generator. > > _______________________________________________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
