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

[Mikael Lyngvig]

I think your suggestion is awesome!

When I first started on this document, ages ago, my goal was to provide
full documentation of the process of building LLVM on Windows using only
MinGW.  The reason for this being that not all LLVM students out there have
the money to buy Microsoft's tools (I do have VS2010, but I prefer a
command-line environment).  MiNGW is free and readily available so I feel
that it is important to support those too.

So far, I've shaved off all references to Intel and Microsoft in my
document because I think it is way more important to document the very
difficult MinGW path than the rather easy MSVC path.  I myself am building
LLVM with VS2010 and I have found no issues in that process, but I think it
would be very valuable to be able to do the test suite without having to
install half the world's GNU ports to Windows :-)

Feel free to send me your binary and I'll see what I can accomplish with
it.  It just might be the thing to avoid CygWin and the rest of the
somewhat annoying packages that currently need to be installed to do the
test.

I definitely feel that this is an outstanding path forward for the Windows
support, because the complicating factor is all those extra tools that
needs to be installed.

I'll be happy to spend the time needed to update the MSVC document to make
use of your tool!


Best Regards,
Mikael


2013/11/13 Alp Toker <alp at nuanti.com>

>
> 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.
>    - 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131113/4acbe1a0/attachment.html>