<p dir="ltr"><br>
On Apr 18, 2013 6:12 AM, "Eric Christopher" <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
><br>
> On Wed, Apr 17, 2013 at 1:05 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>
> > ----- Original Message -----<br>
> >> From: "Jim Grosbach" <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>><br>
> >> To: "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>><br>
> >> Cc: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
> >> Sent: Wednesday, April 17, 2013 2:46:49 PM<br>
> >> Subject: Re: [LLVMdev] make check rebuilds the project?<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> cmake+ninja is a non-option for many developers.<br>
> >><br>
> >><br>
> >> By the way, i'm curious what this means. It can be interpreted in a<br>
> >> number of ways, but it would be good to know what problems you are<br>
> >> specifically saying making it a non-option for many developers<br>
> >><br>
> >><br>
> >> Hi Danny,<br>
> >><br>
> >><br>
> >> Sorry for being unclear. My fault for posting when I’m in a hurry.<br>
> >><br>
> >><br>
> >> I don’t think there’s any unsolvable problems. Well, not technical<br>
> >> ones anyway. It’s a question of supporting a broad enough cross<br>
> >> section of environments and workflows that devs not only can move to<br>
> >> cmake+ninja, but actively want to do so.<br>
> >><br>
> >><br>
> >> For me personally, it’s more a question of supported workflows being<br>
> >> inconvenient than it being a strict non-starter. That is, it’s a<br>
> >> question of which system has fewer inconveniences for me in my daily<br>
> >> work. Right now, that’s configure+make. I’m very much looking<br>
> >> forward to the day when the balance of that equation changes.<br>
> >><br>
> >> Note, I’m explicitly excluding the whole “remove autoconf+make” thing<br>
> >> from this. That’s another topic with a whole extra set of issues.<br>
> >> Likewise, I’m not going to make any sorts of claims about<br>
> >> exhaustiveness here, but rather just relate mostly what I’ve<br>
> >> encountered.<br>
> >><br>
> >><br>
> >> AFAIK ninja still only has very preliminary support for Windows, so<br>
> >> anyone working there can’t use it. Perhaps that’s changed or I’m<br>
> >> misinformed? Last I tried it, OSX support was better, but still very<br>
> >> much “try it and see if it works for you.” I personally found<br>
> >> ninja’s OSX support to be fine, but I didn’t really beat on it to<br>
> >> put it through its paces, either. Relatedly, some work environments<br>
> >> have varying ability to install and use “non-standard” tools. I’ve<br>
> >> been in workplaces before that I’d have had to fight tooth and nail<br>
> >> to get something like cmake or ninja available to me on my<br>
> >> workstation. Even now when I don’t have that policy sort of problem,<br>
> >> it’s still a pain when every time I install a new system (which I do<br>
> >> disturbingly often), I need to install additional tools before I can<br>
> >> start using llvm. Not a big problem on its own of course, but an<br>
> >> inconvenience.<br>
> >><br>
> >><br>
> >> cmake+ninja doesn’t support building and running the llvm test suite.<br>
> >> That’s pure configure+make still. I rely on configure automatically<br>
> >> setting up the test suite to run on whatever compiler I just built.<br>
> >><br>
> >><br>
> >> For example, I build Debug+Asserts, Release+Asserts and Release<br>
> >> configurations all in the same build directory and rely on the<br>
> >> configure+make machinery to create separate build results<br>
> >> subdirectories named for those. That is, it’s pretty common for me<br>
> >> to do something that boils down to (with lots of steps in between of<br>
> >> course), “<src>/configure && make && make check && make<br>
> >> ENABLE_OPTIMIZED=1 && make check ENABLE_OPTIMIZED=1 && make<br>
> >> ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1 && make check<br>
> >> ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1”. Depending on what I’m<br>
> >> doing, I bounce back and forth between them. With cmake, I have to<br>
> >> have completely separate configured build directories. I already<br>
> >> have 10+ llvm build directories lying around that I regularly use.<br>
> >> I’d prefer to keep that number from growing too horribly. When I<br>
> >> last tried using cmake+ninja, this is the one that I kept running<br>
> >> into and getting annoyed with.<br>
> >><br>
> >><br>
> >> Do the cmake scripts support cross-compiling? Last I tried, I had<br>
> >> trouble with that. Many moons ago, I had to beat the plain Makefiles<br>
> >> into some sort of submission for that. I not infrequently build llvm<br>
> >> to run on ARM, for example.<br>
> >><br>
> >><br>
> >> Somewhat relatedly, I like to keep my development builds as close as<br>
> >> reasonably possible to production builds. There are few things that<br>
> >> make my stomach churn more than bugs that only reproduce on the<br>
> >> production builders. That’s somewhat off-topic, though, as that’s<br>
> >> getting into “what would it take to remove configure+make support”<br>
> >> territory.<br>
> >><br>
> >><br>
> >> In short, I’m a big fan of ninja and really want to use it. CMake,<br>
> >> I’m less thrilled about, but I’ll put up with it if it gets me<br>
> >> ninja. Right now though, it’s a close but not quite a fully baked<br>
> >> replacement for my uses.<br>
> >><br>
> >><br>
> >> Anyways, none of this should be construed to be a slight to the work<br>
> >> people have put into cmake+ninja support for llvm/clang. Quite the<br>
> >> opposite. I’m excited enough about what’s been done that I’m<br>
> >> frustrated it doesn’t fit my use-cases well enough for me to switch.<br>
> >><br>
> >><br>
> >> My point with that comment, which Eli correctly and effectively<br>
> >> addressed in his reply, is that we can’t assume we can define away<br>
> >> problems with the configure+make system by just telling people it’s<br>
> >> deprecated and they should use cmake+ninja instead. We’re not there<br>
> >> yet.<br>
> ><br>
> > I'd like to second all of this.<br>
> ><br>
> > Also, I'll add that I also sometimes build on machines where linking a Debug+Asserts clang takes several minutes, and I like to be able to cut off that process to run make check. However, I discovered that if you 'cd test' before running make check, then there are no dependency problems and it will just run the tests with your current build as-is. So long as that works, I'm fine with keeping the top-level make check dependent on the rest of the build.<br>

> ><br>
> ><br>
><br>
> Yeah, check is just: make -C test so that'll work as well.<br>
><br>
> The point was that if you've made source changes you should really<br>
> probably retest what you've changed and the dependency highlights that<br>
> in the normal use case. There are many ways around it, but the general<br>
> goodness should still be there.</p>
<p dir="ltr">Yep, seems to me that it's not an either/or, we can have both, but I think 'make check' should be the date default which includes ensuring the build is up to date. Maybe a 'check-only' target would be nice, rather than having to resort to -C</p>

<p dir="ltr">><br>
> -eric<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</p>