On Wed, Apr 17, 2013 at 10:23 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> On 4/17/2013 12:15 PM, Eric Christopher wrote: > >> >> Give a compelling argument and I might :) >> > > The cost is the extra time spent verifying that the binaries are fresh. > In my experience it has never happened that I ran "make check" on a wrong > set of binaries. On the other hand, it does happen that I run "make check" > repeatedly, when working on a testcase (or a set of testcases), or when I > fixed something that previously caused some testcases to be XFAILed.If development speed / turnaround time is important for you, 'make' is the wrong solution in the first plane. Use a cmake+ninja build, which is way faster, especially for null builds (where all the build system does is make sure there's nothing new to build, or very few things to build). Here's a ninja build run on a fully built debug LLVM+Clang checkout: $ time ninja ninja: no work to do. real 0m0.088s user 0m0.070s sys 0m0.010s You can't beat that with 'make' no matter what you do ;-) Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130417/be9c5ec3/attachment.html>
On Apr 17, 2013, at 10:43 AM, Eli Bendersky <eliben at google.com> wrote:> > > > On Wed, Apr 17, 2013 at 10:23 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 4/17/2013 12:15 PM, Eric Christopher wrote: > > Give a compelling argument and I might :) > > The cost is the extra time spent verifying that the binaries are fresh. In my experience it has never happened that I ran "make check" on a wrong set of binaries. On the other hand, it does happen that I run "make check" repeatedly, when working on a testcase (or a set of testcases), or when I fixed something that previously caused some testcases to be XFAILed. > > If development speed / turnaround time is important for you, 'make' is the wrong solution in the first plane. Use a cmake+ninja build, which is way faster, especially for null builds (where all the build system does is make sure there's nothing new to build, or very few things to build). > > Here's a ninja build run on a fully built debug LLVM+Clang checkout: > > $ time ninja > ninja: no work to do. > > real 0m0.088s > user 0m0.070s > sys 0m0.010s > > You can't beat that with 'make' no matter what you do ;-) >cmake+ninja is a non-option for many developers. Fixing that is a separate problem. We can’t just ignore problems in our configure+make build system in the meantime. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130417/39b214fa/attachment.html>
On Wed, Apr 17, 2013 at 10:53 AM, Jim Grosbach <grosbach at apple.com> wrote:> > On Apr 17, 2013, at 10:43 AM, Eli Bendersky <eliben at google.com> wrote: > > > > > On Wed, Apr 17, 2013 at 10:23 AM, Krzysztof Parzyszek < > kparzysz at codeaurora.org> wrote: > >> On 4/17/2013 12:15 PM, Eric Christopher wrote: >> >>> >>> Give a compelling argument and I might :) >>> >> >> The cost is the extra time spent verifying that the binaries are fresh. >> In my experience it has never happened that I ran "make check" on a wrong >> set of binaries. On the other hand, it does happen that I run "make check" >> repeatedly, when working on a testcase (or a set of testcases), or when I >> fixed something that previously caused some testcases to be XFAILed. > > > If development speed / turnaround time is important for you, 'make' is the > wrong solution in the first plane. Use a cmake+ninja build, which is way > faster, especially for null builds (where all the build system does is make > sure there's nothing new to build, or very few things to build). > > Here's a ninja build run on a fully built debug LLVM+Clang checkout: > > $ time ninja > ninja: no work to do. > > real 0m0.088s > user 0m0.070s > sys 0m0.010s > > You can't beat that with 'make' no matter what you do ;-) > > > cmake+ninja is a non-option for many developers. Fixing that is a separate > problem. We can’t just ignore problems in our configure+make build system > in the meantime. >Understood, and this is why I didn't express an opinion on the original issue. I just thought it may help a fellow developer to point this out if he really cares about the speed of null builds. Personally I've saved a lot of time since switching to ninja a few months ago. Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130417/c1d8bc8d/attachment.html>
FWIW, the cmake build has the "check" target depend on the binaries under test. On Apr 17, 2013, at 10:43 AM, Eli Bendersky <eliben at google.com> wrote:> If development speed / turnaround time is important for you, 'make' is the > wrong solution in the first plane. Use a cmake+ninja build, which is way > faster, especially for null builds (where all the build system does is make > sure there's nothing new to build, or very few things to build).I would 100% recommend it for that reason, but one thing to note is that ninja buffers subprocess output. Usually this is good because you can avoid interleaved diagnostics from multiple source files, but it means "ninja check" buffers lit's output until it's done. That's OK for me when I'm doing final testing for a change, but it means it's not quite a drop-in replacement for "make check".
On Wed, Apr 17, 2013 at 10:53 AM, Jim Grosbach <grosbach at apple.com> wrote:> > On Apr 17, 2013, at 10:43 AM, Eli Bendersky <eliben at google.com> wrote: > > > > > On Wed, Apr 17, 2013 at 10:23 AM, Krzysztof Parzyszek > <kparzysz at codeaurora.org> wrote: >> >> On 4/17/2013 12:15 PM, Eric Christopher wrote: >>> >>> >>> Give a compelling argument and I might :) >> >> >> The cost is the extra time spent verifying that the binaries are fresh. >> In my experience it has never happened that I ran "make check" on a wrong >> set of binaries. On the other hand, it does happen that I run "make check" >> repeatedly, when working on a testcase (or a set of testcases), or when I >> fixed something that previously caused some testcases to be XFAILed. > > > If development speed / turnaround time is important for you, 'make' is the > wrong solution in the first plane. Use a cmake+ninja build, which is way > faster, especially for null builds (where all the build system does is make > sure there's nothing new to build, or very few things to build). > > Here's a ninja build run on a fully built debug LLVM+Clang checkout: > > $ time ninja > ninja: no work to do. > > real 0m0.088s > user 0m0.070s > sys 0m0.010s > > You can't beat that with 'make' no matter what you do ;-) > > > cmake+ninja is a non-option for many developers.By the way, i'm curious what this means. It can be interpreted in a number of ways, but it would be good to know what problems you are specifically saying making it a non-option for many developers