similar to: Looking for developers trying to build Windows apps on Wine

Hi, Yesterday I upgraded to kernel 2.6.8 on my Fedora Core 2 system. This caused a problem with the version of wine I'd been using (20040505), so I upgraded wine to the current version (20040813). The remaining problem is as follows: I'm calling wine like this: wine start.exe vcbuild.bat and vcbuild.bat contains the following: set QMAKESPEC=win32-msvc.net set

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

Hi, I built llvm+Clang for MSVC 10 with cmake ../../Source/LLVM -G"NMake Makefiles" nmake And I tried to do a nmake check (which works for MinGW and "mingw32-make check") and get the following error: >Scanning dependencies of target check >[100%] Running LLVM regression tests >Traceback (most recent call last): > File

Chris Lattner <sabre at nondot.org> writes: [snip] > Others have suggested alternative build systems before like cmake. > Apparently cmake can autogenerate VC++ and Xcode project files from > the same thing that it builds from on unix systems. cmake creating VC++ project files does not appeal much to me. First, project files are not mandatory for using MS compiler. Second,

So I wanted to export a contour3d object into VTK and it worked well enough, except the top of the ball (the contour) was missing. Example below, or gist here: https://gist.github.com/muschellij2/5126544 rm(list=ls()) require(misc3d) f <- function(x, y, z) x^2+y^2+z^2 x <- seq(-2,2,len=20) ball <- contour3d(f,4,x,x,x, draw=FALSE) drawScene.rgl(ball) ### get the triangles allids

At the current time, the environment is using qt3 values, as in $ env | grep QT QTDIR=/usr/lib/qt-3.3 QTINC=/usr/lib/qt-3.3/include QTLIB=/usr/lib/qt-3.3/lib $ env | grep PATH PATH=/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/bin:/usr/bin:/home/pauljohn/bin I also have QT4 installed, and I want programs to find those libraries and include files instead of these ones.

has there been any attempt to improve the 3D visualization (interactive) features in R, using the vtk library? It seems fairly straight forward. maybe even trivial for somebody who has experience with vtk library. let me know if there are any obvious reasons i may have overlooked thanks, in advance for any feedback -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-

On Sunday 18 May 2008, Óscar Fuentes wrote: > Chris Lattner <sabre at nondot.org> writes: > > [snip] > > > Others have suggested alternative build systems before like cmake. > > Apparently cmake can autogenerate VC++ and Xcode project files from > > the same thing that it builds from on unix systems. > > cmake creating VC++ project files does not appeal

On May 17, 2008, at 2:44 PM, Óscar Fuentes wrote: > I don't know how much LLVM build system is tied to the GNU toolchain > or > how much it depends on *nix features, but suppossing that adding > support > for MSVC++ is impractical, perhaps it would be simpler to implement a > Makefile-based build system for MSVC++ than to keep up to date the > project files. This would

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

Hello, I'm attempting to create a smooth, 3D plot of a trajectory (rather than the cloud or wireframe functions). I would rather the individual data points not be visible. I've had no luck finding this on the graphics or help pages. Thank you in advance. Chris Some example data, just in case: 25 32 40 12 25 32 2 12 25 2 2 12 20 2 2 1 20 2 6 1 20 5 6 1 5 5 6

I have filed a number of problem reports about getting the LLVM test infrastructure working for an environment with: Windows + MSVC9 + Cmake + NMake makefiles + MKS. (MKS provides unix-like tools for Windows, but based on very old versions, so they have quirky or minimal compatibility with GNU tools.) http://llvm.org/bugs/show_bug.cgi?id=9689 - Fix Cmake generation of compile_cxx for MSVC -

>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