On Wed, Apr 17, 2013 at 10:05 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:> On 4/17/2013 11:50 AM, Eric Christopher wrote: >> >> Because almost no other piece of software out there doesn't have >> 'check' depend on rebuilding the target it's testing and it's bitten >> people whereas other than the lameness of our build system needing to >> recurse all the directories to figure out that all has already been >> rebuilt there's no penalty to requiring the dependency. :) > > > Given this explanation my vote goes for reverting it. :) >Give a compelling argument and I might :) -eric
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. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On 4/17/2013 12:23 PM, Krzysztof Parzyszek wrote:> > 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.I don't know if this is compelling enough, since it hinges on my own working habits. It would be interesting to see the more opinions about it. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
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. >The extra cost is pretty trivial and you can run individual test cases by using lit explicitly. We've had annoying bot failures because someone ran "make check" but it didn't rebuild the targets that check depends upon. On my laptop it's a total of 4 seconds to get to check... you probably would save more time by running lit explicitly on a testcase you're changing :) -eric
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>