New testing workflow for Windows (was Re: [PATCH] [DOCS] How to Setup a Windows Builder)

Thu Nov 14 14:39:59 PST 2013

Rick,

Agree that this doesn't impact the documentation directly. The existing
testing procedures will stay around for some time, if not forever,
alongside any new system so it's great to document them for Zorg.

Just to clarify, the patched program isn't bash, but BusyBox which is
equivalent to the whole of MSYS or the Cygwin environment within a
single self-contained binary including a shell, grep, diff, patch etc.

So the tester wouldn't be expected to build it, but would just download
and install it as a drop-in binary alternative to installing a Unix
layer on the PC.

Will move the BusyBox thread to llvm-dev, thanks for the suggestions.

Regards,
Alp.

On 13/11/2013 18:55, Rick Foos wrote:
> *** the attachment is only to clarify this discussion, and not a
> proposed change. Mikael is working on the next change***
>
> 1) I agree with a some of this discussion, but I am concerned that we
> are getting away from a one page guide to provision a general purpose
> Windows Builder.
>
> Completing all the steps results in a builder suitable for integration
> with Zorg.
>
> The order of the sections is important for installation, and the
> original didn't have enough of that.
>
> I made a revision that only Mikael has to correct the flow, and allow
> optional components as Reid suggested. I'll attach it here for
> discussion. (Mikael is making the final changes and clarifications).
>
> 2) The build machine should have the ability to build in multiple
> environments that you would encounter on Windows. Msys, Cygwin, DOS.
>
> When all packages are installed, it can be done by setting paths prior
> to invoking one of the Bourne shells. I envision Buildbot/Zorg making
> this build environment selection.
>
> The new section layout allows the user to skip some subsections, and
> come up with a more specific build machine.
>
> 3) In regards to the modified Bash, we are running the test suite for
> llvm, clang, and polly. I think a specialized bash is fine, but to me
> it is one more option that the build machine can do. It doesn't take
> away from the packages that are in place.
>
> I'm a little concerned with a patched bash that the user cannot build,
> or needs to set up another build environment to recreate, but that can
> be addressed.
>
> 4) In the attached document, MSVC has a small section to avoid some
> pitfalls to avoid when using it to build LLVM. I agree that it is NOT
> important to say anything about installing a commercial product.
>
> 5) What is simple, and what is complicated depends on what you are
> doing...
>
> As a developer, a windows build machine should build llvm one way.
>
> This setup is a bit complicated in that regard.
>
> As someone using a buildbot infrastructure, a windows build machine
> needs a complete set of standard packages that build and test LLVM all
> ways possible. Then I can replicate a number of buildslaves, and it is
> simple to select a host and spread out the workload.
>
> This setup is simple in that regard.
>
> Best Regards,
> Rick Foos
>
> On 11/13/2013 12:04 PM, Reid Kleckner wrote:
>> This sounds awesome!  It would be really great for developers that
>> just want to use VS as well.  No need to go and choose one of the
>> various sets of Unix tools for Windows that are all slightly
>> incompatible in different obscure ways.
>>
>>
>> On Wed, Nov 13, 2013 at 1:07 AM, Alp Toker <alp at nuanti.com
>> <mailto:alp at nuanti.com>> wrote:
>>
>>
>>     On 13/11/2013 01:06, Sean Silva wrote:
>>>
>>>     +**Notice:** If you do not plan to run the test suite, or sshd
>>>     server, you don't
>>>     +need Cygwin. You can build LLVM + Clang with only Subversion,
>>>     MingwNN, and CMake.
>>>
>>>     I feel like the way you are handling these notices is backwards.
>>
>>     This is all very complicated and difficult to document!
>>
>>     I'd like to share an alternative..
>>
>>     At Nuanti we have a setup that can run the full test suite
>>     natively on Windows using only the native Microsoft toolchain and
>>     a special BusyBox binary, so we don't even install MingW or
>>     Cygwin on Windows development systems.
>>
>>     This has a number of benefits:
>>
>>       * Full test coverage. Our BusyBox is patched to be compatible
>>         with Unix so we get to run tests that would usually fail due
>>         to REQURES/XFAIL mingw/shell/shell-preserves-root.
>>       * No need for Administrator access. There is nothing to
>>         install, no GNU this or that, just a fresh SVN/git checkout
>>         from llvm.org <http://llvm.org>.
>>       * Easy to set up. Just drop the single binary in your PATH or
>>         lit folder.
>>       * Escaping and /dev/null hacks for Windows in lit are no longer
>>         needed.
>>       * Full in-process execution. Forking is slow on Windows, but
>>         with our approach a full test suite run is reduced close to
>>         native timings comparable to other platforms.
>>
>>     I was planning to upstream this work later in the 3.5 cycle but
>>     looking at how painful the process is at present, and more so the
>>     effort to document it, I feel now like it might be worth pushing
>>     ahead earlier.
>>
>>     The patch to lit itself is very small / low-impact and most of
>>     the work is in BusyBox itself.
>>
>>     I can get this work Open Sourced along with a build of the
>>     drop-in llvm-busybox.exe later today if it sounds desirable.
>>
>>     Certainly it'd reduce much of this document to just "Copy
>>     llvm-busybox.exe into your PATH"
>>
>>     How does this sound?
>>
>>     If you like the idea, let me know soon as today's the best time
>>     for me to pull this all together and post the lit side of the
>>     work for review.
>>
>>     Regards,
>>     Alp.
>>
>>     -- 
>>     http://www.nuanti.com
>>     the browser experts
>>
>>
>>     _______________________________________________
>>     llvm-commits mailing list
>>     llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>>     http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
> -- 
> Rick Foos
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-- 
http://www.nuanti.com
the browser experts