search for: msbuild

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 clang-cl.exe for cl.exe and thereby take advantage of msbuild supplying correct flags, include paths et cetera. What's the recommended procedure for this - rename clang-cl.exe to cl.exe and put it ear...

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

...th 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 anytime I do change them. I also use the "Build" rather than "Rebuild" for incremental development. MartinO -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.l...

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, and discussion in: https://social.msdn.microsoft.com/Forums/vstudio/en-US/1a6dd13c-9f5c-430b-88ba-518b...

..., 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 that substitutes clang-cl - with that removed, everything is successful) The build failed with the following error message: Tracking command: C:\Program Files (x86)\MSBuild\12.0\bin\Tracker.exe /d "C:\P...

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 some set of link-time...

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

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

...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 the projects that are to be built. 2) The "ZeroCheck" project runs and cmake is rerun if any of the CMakeLists.txt files have been updated. 3) The build continues for each of the projects, using the dependen...

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

...dencies 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<mailto: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 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 some set of link-time...

...12.0\VC\include\algorithm:6: 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory:6: 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0:909: 1> In file included from C:\Program Files (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\intrin.h:34: 1> In file included from C:\Program Files (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\x86intrin.h:29: 1> In file included from C:\Program Files (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\immintrin.h:28: 1>C:\Program Files (x86)\...

...uler >> >> On Mon, Sep 29, 2014 at 7:38 PM, Eric Mader <emader at gmx.us >> <mailto:emader at gmx.us>> wrote: >> >> I changed tooset-vs2013.props to this: >> >> <Project >> xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >> <http://schemas.microsoft.com/developer/msbuild/2003>> >> <Import >> Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Microsoft.Cpp.$(Platform).v120.props"Condition="Exists('$(VCTargetsPath)\Platforms\...

...nstallDir>"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" > <http://schemas.microsoft.com/developer/msbuild/2003>> > <Import > Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Microsoft.Cpp.$(Platform).v120.props" > Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\Platfo...

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/1b6a51a1425cc0180359ecd64733edb965f...

...too. I'll try copying the x64 toolsets by > hand to see what happens > > Regards, > Eric Mader > > On 9/29/14, 9:38 AM, Rafael Auler wrote: > > I was not necessarily asking you to build, but just to check your > installation folder and see whether you have "tools/msbuild/install.bat" > there because I don't know if the Windows installer puts this there. > However, if you want to build outside VS, I recommend mingw-w64. If you > have any difficulties about the VS build process though, feel free to ask > questions :-) > > Usually, to build...

...n 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 source code, you should be able to go to the > installation folder, find a subfolder named "tools/msbuild" and run > the "install.bat" script. This should make your LLVM toolset appear in VS. > > On Mon, Sep 29, 2014 at 2:52 PM, Eric Mader <emader at gmx.us > <mailto:emader at gmx.us>> wrote: > > I’m trying to install LLVM-3.6.0-r218288-win32.exe on Wi...

I have to change a file in c:\Program Files <x86>\MSBuild\Microsoft.Cpp\v4.0. I have tried various ways to encapsule the Windows path with spaces but to no avail. The following file { "\"c:\\program files <x86>\\MSBuild\\Microsoft.Cpp\\v4.0\\Microsoft.CppCommon.targets\"": ensure => present, source =...

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 like some ki...

...the DLL I'm >> trying to build) >> >> Regards, >> Eric Mader >> >> >> On 9/30/14, 1:01 PM, Eric Mader wrote: >> >> 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, >> E...