[LLVMdev] make check rebuilds the project?

Eli Bendersky eliben at google.com
Wed Apr 17 11:02:17 PDT 2013


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>


More information about the llvm-dev mailing list