similar to: [LLVMdev] LLVM toolchain for Visual Studio

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

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 >

pls read the page of http://llvm.org/builds/ : To use the LLVM toolchain from Visual Studio, select a project in Solution Explorer, open its Property Page (Alt+F7 by default), and in the "General" section of "Configuration Properties" change "Platform Toolset" to "LLVM-vs2010" or "LLVM-vs2012". Alternatively, invoke MSBuild with

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

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" >

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

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

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

On Fri, Jul 10, 2015 at 2:00 AM, Chandler Carruth <chandlerc at google.com> wrote: > This seems more relevant to cfe-dev. > Okay. > > You seem to be struggling with the need to name the binary 'cl.exe'. Last > time I checked, we installed clang-cl.exe under that name in a specialized > director specifically so you can use build systems relying on that name. >

Hi, I have tagged 3.6.2-final, so testers can start building and uploading -final binaries. There was only one change between 3.6.2-rc1 and 3.6.2-final, which was a patch to the R600 backend to fix the build with VS2012. Running a full regression suite is probably not necessary, but you still can if you want to be extra careful. -Tom

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C39C9F.B5DABBD0 Content-Type: text/plain; charset="iso-8859-1" # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing

I am using C code to create an S4 object based on Douglas Bates's example in his lecture notes on <http://www.ci.tuwien.ac.at/Conferences/DSC-2003/Tutorials/RExtensions/slide s.pdf> http://www.ci.tuwien.ac.at/Conferences/DSC-2003/Tutorials/RExtensions/slides .pdf e.g. SEXP La_DGE_dc(SEXP A) { SEXP aa = PROTECT(duplicate(A)); SEXP adims, pivot, val; int

Hello, I have attempted to install samba36 on a base install of FreeBSD 9.2 I have installed this same package about 30 days ago and had no problems what so ever. after the install, I add the line to FreeBSD /etc/rc.conf file - samba_enable="YES" Reboot the server and an error appears - WARNING /var/db/samba is not a directory I make the basic smb.conf changes like I have always

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

I think MSBuild isn't capable of re-running cmake and then reloading the project files when CMakeLists.txt changes. It re-runs cmake, but then continues the build with the stale projects. That probably explains the "PipSqueek.cxx doesn't exist" errors. As for the link error, it could also be caused by things like a file rename not getting picked up by MSBuild. The fix is

With VS2013 I found that editing a CMakeLists.txt file caused CMake to be re-run successfully and the build to also continue successfully, but since I switched to VS2015 the CMake re-run occurs - apparently successfully, but more often than not the build failed afterwards from either the IDE and from MSBuild. Since I seldom change the CMakeLists.txt files, I simply do a clean CMake configuration

I'm trying to build LLVM 3.5.1 on Windows, almost successfully; the remaining stumbling block is getting static linking for release builds. The problem is that the .vcxproj is interpreted by msbuild to compile with the /MD option instead of /MT, as detailed in: https://stackoverflow.com/questions/28262372/getting-msbuild-to-use-mt-staticrelease Haven't got any answers on that question,

What kind of missing symbols are you getting? I had to work around dependencies for a Mingw32 build. See https://reviews.llvm.org/D44650 On Wed, May 16, 2018, 13:13 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I have the git monorepo, and Visual Studio 2015. I am finding that > running a build from the command line with msbuild (as a nightly job) > invariably fails on the

I have the git monorepo, and Visual Studio 2015. I am finding that running a build from the command line with msbuild (as a nightly job) invariably fails on the first try, and succeeds on a retry. The first msbuild command looks like this: msbuild ALL_BUILD.vcxproj /p:Configuration="RelWithDebInfo" /m:6 /t:Rebuild This appears to compile everything okay, but invariably fails with

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3738F.63DE3390 Content-Type: text/plain; charset="iso-8859-1" #I want to be able to create a new S4 class and read data into it using C code # Here is a very simple S4 object inheriting from "array", but with 5