similar to: [LLVMdev] RFC: "Building with MinGW on Windows" (DOC, NEW)

For those interested in the actual file, it is now attached. ---------- Forwarded message ---------- From: Mikael Lyngvig <mikael at lyngvig.org> Date: 2012/6/16 Subject: RFC: "Building with MinGW on Windows" (DOC, NEW) To: LLVMdev Mailing List <llvmdev at cs.uiuc.edu> Here's the first part of my Windows set up documentation. This one only covers the process of

Mikael, Thanks for working on. My gross comments... - Canonical URL of LLVM project is; http://llvm.org/ , not www.llvm.org. - "test-suite and cygwin" could be split out. It would be special thing. - Memory/storage requirements would be moved to "A.B Debugging". Less memory would be enough without debug build. - Python (x64 binary) is available, too. I am using. Python

Hi Takumi, THANK YOU for your excellent review! It makes all the work worthwhile in itself. It is getting "late" here (it is early morning) so I am about to call it a day. But I will contemplate and incorporate your suggestions tomorrow, and send you a full reply. I think I originally wrote a document where I addressed both Visual Studio and MinGW, but then decided that there were

On Sat, Jun 16, 2012 at 3:29 AM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi Takumi, > > THANK YOU for your excellent review! It makes all the work worthwhile in > itself. > > It is getting "late" here (it is early morning) so I am about to call it a > day. But I will contemplate and incorporate your suggestions tomorrow, and > send you a full

Oh, didn't realize that there already is a semi-official build of CMake with Ninja support. I am trying it out right now and it seems very promising. So I'll change the document to use Ninja instead of "MinGW Makefiles". No need to waste energy on MinGW and MSYS Makefiles when Ninja outdoes them both. I thought people would have to build CMake themselves, something I'd

Now I can't make CMake use "MSYS Makefiles". I get an error about GNU v4.7.0 being broken as it can't build a simple test program. Using "MinGW Makefiles", everything works out of the box. And I am trying to give the user the most Windowsy experience (to avoid Cygwin, GnuWin32, and MSYS, if I can). So I think I'll stick to my current angle - which is to let the

As for Ninja, I'd like to wait until it is officially part of the released CMake. As I understand it, Windows support has been checked into the CMake repository but no offical release supporting Ninja has been made yet. I just retrieved Ninja from Github and this time it built without problems. 2012/6/16 NAKAMURA Takumi <geek4civic at gmail.com> > Mikael, > > Thanks for

2012/5/24 Mikael Lyngvig <mikael at lyngvig.org>: > I know that the documentation says that I am to install GnuWin32 tools, but > I strongly oppose that idea.  We Windows people have our own tools and > practices and I think the LLVM developers should open up to a more > multi-platform approach than the current (Unix then, perhaps maybe, Windows) > approach.  CMake works

Hi again, The Visual Studio getting started guide ( http://llvm.org/docs/GettingStartedVS.html) mentions the "llvm-lit" tool, but fails to mention these things: 1. Either you need to run it from bash or a similar Unix shell, as Windows does not recognize the extensionless Python script that it is. 2. Alternatively, you can invoke it using Python like this: python bin/llvm-lit

As for memory/storage, I think you want these presented as early as possible so people don't go setting up a box only to find out, half a week later, that they can never do what they intended to do (build Clang in debug mode). The reason I use 32-bit Python is that it is what you need, if you want to make a Windows buildbot slave because the Win32 bindings are needed and I don't think

I have filed a number of problem reports about getting the LLVM test infrastructure working for an environment with: Windows + MSVC9 + Cmake + NMake makefiles + MKS. (MKS provides unix-like tools for Windows, but based on very old versions, so they have quirky or minimal compatibility with GNU tools.) http://llvm.org/bugs/show_bug.cgi?id=9689 - Fix Cmake generation of compile_cxx for MSVC -

Good morning David, I won't accept your patches for now. It breaks lots of things in current environments, autoconf - msys, cmake - msys, cmake -mingw and cmake - msvs. - You should never forget other environments. (eg., MSYS and CMD.EXE) You should implement detecting MKS if you tweak MKS-specific stuff. - Bash should be assumed to be mature. I suppose MKS bash might be

Hi all, Here's an updated version of my proposed "Building with MinGW on Windows" document. In summary, the document gives a step-by-step description of how to build LLVM + Clang on Windows WITHOUT having Microsoft Visual Studio installed. The high-level goal of the document is to make life pleasant for those wonderful Windows users who desire to try out LLVM and/or Clang. I

Hi, The language reference uses "::" many places where it seems it should be using ".. code-block:: llvm". The result is that Sphinx does not colorize these samples. Should I fix this? Or is it purposeful? Also, anybody but me that has noticed that Sphinx does not always colorize things even if you put the proper ".. code-block:: llvm" in front? If it is a known

On Sun, Nov 24, 2013 at 10:19 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi, > > The language reference uses "::" many places where it seems it should be > using ".. code-block:: llvm". The result is that Sphinx does not colorize > these samples. > > Should I fix this? Or is it purposeful? > Could you give an example of what you are

Am I the only one who thinks that it is impractical that the Sphinx intro is buried deep within the lld documentation? I suggest moving it to the Programming Documentation document. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120616/2cb7356d/attachment.html>

On the other hand, it's the first result on google for "llvm sphinx". --Sean Silva On Fri, Jun 15, 2012 at 4:44 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Am I the only one who thinks that it is impractical that the Sphinx intro > is buried deep within the lld documentation? I suggest moving it to the > Programming Documentation document. > > >

On Mon, Jun 18, 2012 at 12:25 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi all, > >     3. The document now covers 32-bit and 64-bit builds with MinGW tools (if > anybody know of an alternate BINARY distribution of MinGW64 than Drangon's > release, please let me know so I can include it in the document). As was once explained to me by Ruben Van Boxem, what you

On Sat, Jun 9, 2012 at 12:40 AM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi, > > Here's the final, confirmed working version of my Windows guide for how to > set up a MinGW buildbot slave. Please consider to include it in the > documentation on the LLVM website. > > Basically, it saves the newcoming Windows user about two or three days of >

On Fri, Jun 15, 2012 at 4:44 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Am I the only one who thinks that it is impractical that the Sphinx intro is > buried deep within the lld documentation?  I suggest moving it to the > Programming Documentation document. Agreed that it needs to move to llvm proper, this was always the plan. I think the only thing we were waiting on was