similar to: [LLVMdev] msbuild and clang

Okay, so trying a straight compile of the Python interpreter with clang-cl, I used the following commands: cd \python-2.7.10\pcbuild copy C:\llvm\build\Release\bin\clang-cl.exe cl.exe rd /q /s amd64 rd /q /s win32-temp-debug rd /q /s win32-temp-release rd /q /s x64-temp-debug rd /q /s x64-temp-release msbuild /p:Configuration=Release /v:diag /fileLogger pcbuild.sln (The second line is the one

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,

Hi, Starting with LLVM 6, MSBuild incremental builds stopped working. I've tracked this down to a CL that modified how file renaming was done on Windows. It appears that FileTracker does not recognize renaming a file with SetFileInformationByHandle. https://github.com/llvm-mirror/llvm/commit/1b6a51a1425cc0180359ecd64733edb965f65d7c#diff-70db51c38d748dc9debf5f309643fcd8 You can repro this

Hi Russel, I never tried to build LLVM with nmake. With msbuild it works without problems. You can find a short desription here: http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC, section Build LLVM. Regards Kai On 24.08.2013 21:15, Russell Wallace wrote: > I'm trying to build LLVM 3.3 using cmake/nmake, Microsoft C++ 2012, on a > 64-bit Windows 7 system. I

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

I'm trying to get clang 3.6.1 to compile itself on Windows, using this command line: msbuild /p:Configuration=Release /p:CLToolExe=clang-cl.exe /p:CLToolPath=c:\llvm\build\Release\bin\ /p:TrackFileAccess=false /p:Platform="x64" /fileLogger ALL_BUILD.vcxproj It barfed on an occurrence of __try but that was only in a test file so I commented it out and retried. Now it's getting

I'm trying to build LLVM 3.3 using cmake/nmake, Microsoft C++ 2012, on a 64-bit Windows 7 system. I tried it with the 32-bit compiler as a test case first and that appeared to work, then with the 64-bit compiler in the hope that would give me a 64-bit build of LLVM, but instead got this error message: [ 86%] Generating X86CompilationCallback_Win64.obj Microsoft (R) Macro Assembler (x64)

It looks like building ZERO_CHECK first to reconstruct the project files as needed, then running msbuild a second time to do the actual build, has solved the problem. At least, last night's run didn't take the usual two tries. Running msbuild twice is a little bit simpler than running cmake explicitly, the way I have my scripts set up, but I'm sure that would work as well. Thanks

>From my own experience this is what I think happens when building the whole solution through Visual Studio's UI. This also happens for building individual projects. I assume something similar happens when building via the command-line, but I rarely do that, so I can't be certain. 1) Visual Studio/MSBuild (I don't know which, but probably MSBuild) determines the dependency graph of

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

msbuild is is able to re-run cmake if a CMakeLists.txt changes. CMake adds a special project "ZERO_CHECK" that does this. However, I am not sure it runs when invoking on the individual projects instead of the solution. Try the cmake --build command, which should output the following: > cmake --build . --target opt CMake is re-running because

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

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

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

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

Here are a couple of representative errors. C:\Dev\upstream\gitmono is where I keep my clone. "C:\Dev\upstream\gitmono\wbuild\ALL_BUILD.vcxproj" (Rebuild target) (1) -> "C:\Dev\upstream\gitmono\wbuild\unittests\Support\DynamicLibrary\SecondLib.vcxproj" (default target) (170:2) -> c1xx : fatal error C1083: Cannot open source file:

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

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]