[PATCH] [zorg] Support Windows/Linux Clang CMake builds with unified builder.

[Rick Foos]

I completely agree with several other testers.

I have a Windows/Linux staging environment set up on my servers, but 
this will catch all of the things I might miss.

--rick

On 01/09/2015 11:18 AM, Renato Golin wrote:
> Overall, looks good. I think we're getting there. I'll wait until you finish your refactoring based on your comments and look at my comments.
>
> To actually put this in production, I'd be a lot more confident if we could make it run on a staging environment before changing it. So, whenever you're happy with it, I'll apply the patch on my local buildmaster and set it to run with my boards. Other interested parties can do the same, and when everyone is happy, we push and apply.
>
> cheers,
> --renato
>
>
> REPOSITORY
>    rL LLVM
>
> ================
> Comment at: zorg/buildbot/builders/ClangBuilder.py:508
> @@ -453,1 +507,3 @@
>   
> +            # Phase 2 build with built Clang.
> +            cmakeGenerator2='Ninja',
> ----------------
> rfoos wrote:
>> This is original behavior but allows the caller to pass an entire step 2 definition.
>>
>> The only exception is the stage1/stage2 framework for the built compiler(s).
> Maybe better as a dictionary? Like:
>
>      build { stage : 1, { cmd = "ninja", install = cmd + " install", check = cmd + " check-all" }
>                stage : 2, { cmd = "ninja", install = cmd + " install", check = cmd + " check-all" } }
>
> or whatever Python would do for something like that. :)
>
> ================
> Comment at: zorg/buildbot/builders/ClangBuilder.py:539
> @@ -481,3 +538,3 @@
>       # Extra stuff that will be built/tested
>       if checkout_clang_tools_extra:
>           f.addStep(SVN(name='svn-clang-tools-extra',
> ----------------
> getClangSource already checks out clang-tools-extra
>
> ================
> Comment at: zorg/buildbot/builders/ClangBuilder.py:595
> @@ -510,16 +594,3 @@
>       ############# CLEANING
> -    if clean:
> -        f.addStep(ShellCommand(name='clean stage 1',
> -                               command=['rm','-rf',stage1_build],
> -                               warnOnFailure=True,
> -                               description='cleaning stage 1',
> -                               descriptionDone='clean',
> -                               workdir='.',
> -                               env=env))
> -    else:
> -        f.addStep(SetProperty(name="check ninja files 1",
> -                              workdir=stage1_build,
> -                              command=["sh", "-c",
> -                                       "test -e build.ninja && echo OK || echo Missing"],
> -                              flunkOnFailure=False,
> -                              property="exists_ninja_1"))
> +    doCleanIf = lambda step: step.build.getProperty("clean") or clean
> +    f.addStep(RemoveDirectory(name='clean stage 1',
> ----------------
> I'm not sure why you set the property here, since this is normally a config option, not a run-time one.
>
> But this could be potentially good if we can detect failure on previous runs and automatically clean after every failure, to make sure it's not an infrastructure failure. Not for this iteration, though.
>
> http://reviews.llvm.org/D6866
>
> EMAIL PREFERENCES
>    http://reviews.llvm.org/settings/panel/emailpreferences/
>
>

-- 
Rick Foos
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project