similar to: [LLVMdev] Windows Installer

I was hoping to not have to build LLVM myself, especially on Windows. Can anybody help me with the Windows installer? Failing that, I find the directions for how to compile on Windows hard to follow? Can I build using Cygwin? Regards, Eric On 9/29/14, 8:11 AM, Rafael Auler wrote: > I'm not sure about the Windows installer, but if you build and install > LLVM for Windows from the

Open the file toolset-vs2013.props and you'll understand what's happening and where the path is set. It tries to fetch the LLVM installation path from the Windows registry. Just fix this (maybe editing your registry or editing the .props file, whatever suits you best). On Mon, Sep 29, 2014 at 5:33 PM, Eric Mader <emader at gmx.us> wrote: > I copied the x64 toolsets by hand and

Your install dir has a whitespace. Have you tried quoting? e.g. <LLVMInstallDir>"C:\Program Files (x86)\LLVM"</LLVMInstallDir> Best regards, Rafael Auler On Mon, Sep 29, 2014 at 7:38 PM, Eric Mader <emader at gmx.us> wrote: > I changed tooset-vs2013.props to this: > > <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >

I replaced all instances of "$(Platform)" with "x64" for the x64 .props file and it still fails, so it looks like that guess was wrong as well. Regards, Eric On 9/29/14, 2:11 PM, Eric Mader wrote: > Quoting doesn't seem to make a difference. Strangely, the Win32 > toolset seems to work. (Where "work" means that clang runs and > produces a bunch of

Hi Hans, I think installer.bat found my visual Studio installation because it installed the Win32 toolsets but not the x64 ones. (It took me a while to work this out ;-) I installed the x64 toolsets by hand and they seem to work. I think the installer ran as administrator. I explicitly ran it that way again (asking it to uninstall first) just to be sure. It didn't seem to make any

Hi Hans, Answers inline below. Regards, Eric On 9/30/14, 8:05 AM, Hans Wennborg wrote: > On Mon, Sep 29, 2014 at 7:56 PM, Eric Mader <emader at gmx.us> wrote: >> Hi Hans, >> >> I think installer.bat found my visual Studio installation because it >> installed the Win32 toolsets but not the x64 ones. (It took me a while to >> work this out ;-) I installed

We inject a typedef for size_t here: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?revision=218230&view=markup#l206 The typedef type is determined by calling getSizeType(). SizeType is (relevantly) calculated in two places: X86_64 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3512 X86_32

Hi Reid, I copied the x64 toolsets by hand; they got installed to C:\Program Files (x86)\LLVM\tools\msbuild\x64; they just didn't get moved correctly by install.bat. I just verified that the LLVM-vs2013 toolset.props is correct. If it is a bitness problem, perhaps I'm failing to define something correctly? Regards, Eric On 9/30/14, 11:29 AM, Reid Kleckner wrote: > This looks

I believe that we provide a definition of size_t inside the compiler itself when clang is in MSVC compatibility mode. On Tue, Sep 30, 2014 at 5:51 PM, Eric Mader <emader at gmx.us> wrote: > I did some more investigation of the size_t size error. I misunderstood > what was happening. It turns out that size_t is already defined before my > prefix header is included. I added the

I'm getting compile errors because size_t is getting redefined. My "forced include file" starts with: #if BUILDING_FOR_WINDOWS #define NOMINMAX /* deal with the fact that windef.h also defines BOOL */ #define BOOL WINBOOL #include <windows.h> #include <intrin.h> #undef BOOL #endif Looking at the preprocessor expansion of a typical .cpp file, I see that crtdefs.h

I'm trying to port a bunch of code from MacOS X to Windows. The code is a mixture of C, C++11 and Objective-C. (Some of the C++ code has bits of Objective-C mixed in, just for spice ;-) Since it builds on the Mac with clang, I thought that building on Windows with clang would mean that I wouldn't have to make a bunch of changes just related to a different compiler. For example, if I

Hi Reid, Thanks for the reply. Comments inline below. Regards, Eric On 9/29/14, 5:51 PM, Reid Kleckner wrote: > I think any port will involve some changes, but it's really hard to > say which porting approach will be the least painless beforehand. > Aside from _MSC_VER incompatibilities messing up portability headers, > I think any changes you make to support clang on Windows

I'm trying to compile some C++ code on Windows that contains blocks. The compiler gives me the error that the blocks language feature is not enabled and that I should enable it with "-fblocks". When I add that compiler flag, the compile fails immediately saying "unknown argument: '-fblocks'" Is this perhaps an incomplete feature? Regards, Eric Mader

I have some C++ source files that mix in small bits of Obj-C. On the Mac, these files are marked to be compiled as Obj-C++. Looking at the clang help, it seems that the option for that is "-ObjC++". However, when I add that in Additional Options I get an error message: CL> : error : invalid integral value 'bjC++' in '-ObjC++' I see this same message if I put

>From this website: http://llvm.org/builds/ I've installed the LLVM toolchain on 2 Windows machines. One with Visual Studio 2012 and another with Visual Studio 2013. After installing the LLVM toolchain neither machine shows the LLVM option in the Visual Studio project properties pane where you can select which toolchain to use for the project. Am I missing a step somewhere? :) Thanks for

Thanks for the reply Reid! I took a look at that script and found that the files were properly copied so I poked around some more. I found that if I started a new win32 console application, LLVM shows up in the toolchain drop down! But if I open another project file from an existing project to see if it compiles in LLVM the dropdown options are missing! Do you know what might be deciding when

I'm having a strange problem compiling with VS 2013. It's not finding a header file that's there in one of the header file search dirs. Here's the compile command (with the names changed to protect the innocent ;-) 1> C:\Program Files (x86)\LLVM\msbuild-bin\CL.exe /c /IC:\[top-level-dir]\[source-dir]\ /IC:\[top-level-dir]\[source-dir]\[sub-dir-1]

Looks like the PlatformToolsets are cached in the .suo file. If you move it out of the way or delete it, VS will re-scan for toolsets. I'm not sure what other user state is stored there, though. That's annoying. =/ On Tue, Dec 3, 2013 at 6:37 AM, Kelly Sommers <kell.sommers at gmail.com>wrote: > Thanks for the reply Reid! I took a look at that script and found that the >

Getting the platform toolsets installed in the right place is a dirty job handled by this script: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/msbuild/install.bat?view=markup Do you have a PlatformToolsets directory somewhere under ProgFiles/MSBuild? If so, where is it? We can add it to the path search. If anyone has better ideas on how to find this magical directory, suggestions are

I'm trying to compile some large programs with clang on Windows (with a view to compiling to bit code and then running some whole program optimisations on the bit code). Take for example the Python 2.7 interpreter: As is typically the case, the usual build procedure involves running msbuild which invokes the Microsoft compiler. The most obvious procedure would then be to substitute