similar to: Windows build strangeness

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

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:

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

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

>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

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

Hi all, I run a build bot which updates and builds trunk llvm on a variety of OSes once every four hours. The windows build has been broken since r246156: http://104.154.46.123:8010/builders/win-64-trunk. A full clean didn't seem to fix it. Neither did several more recent updates (I'm currently building at 246208). The specific error is at the end of this log:

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

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

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,

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 configured with this command: " cmake ../llvm -G"Visual Studio 16 2019" -A Win32 -Thost=x64 -DLLVM_ENABLE_EH=ON -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_CRT_RELEASE=MT -DLLVM_ENABLE_RTTI=ON -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;libcxx;libcxxabi" -DCMAKE_CXX_FLAGS="/permissive- /D_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS" -DCMAKE_CXX_STANDARD=17 "

2012/6/16 Justin Holewinski <justin.holewinski at gmail.com>: > Under Python installation, you mention that Python is only needed for the > test suite.  This is not true, as the normal LLVM build still requires > Python. That's right. Now, python>=2.4 is essential. (In contrast, perl is not required, IIRC) > I would seriously consider splitting this up into

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

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

RFC: lld- Add visual studio compatible diagnostics output to lld Hello all, We have a proposal to extend the diagnostics output capabilities of lld. ## Problem MS Visual Studio expects the diagnostic output of build tools to conform to a specific format, described here: [1] and [2] . Currently lld cannot emit warnings and errors in this format. lld prefixes diagnostic output with args[0],

What is the purpose of supporting this "copy directories around" sort of build strategy anyway? At the end of the day, the way these packages get installed is via system package managers is independently, each project finding its dependencies with the standard prefix path. When I compile from source it's always like this: $ cd llvm-6.0.0rc2.src/ $ mkdir build $ cd build $ cmake ..

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)

Hi, I’d just like to interject to say that building within Visual Studio isn’t really that bad. Running the lit tests is a bit painful because the LLVM build tools that are integrated with the build system don’t play nice with msbuild. Particularly, I’ve never been able to actually cancel an invocation of lit or tablegen via visual studio. That said, there is a huge upside to building with