similar to: [LLVMdev] State of CMake build system.

This is an updated version of the patch that fixes some issues on VC++ builds. -- Oscar -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake.patch Type: text/x-patch Size: 73590 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080921/687284b5/attachment.bin>

On Sun, Sep 21, 2008 at 9:27 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > This is an updated version of the patch that fixes some issues on VC++ > builds. Hi, FYI I just tried this (from r56534). I get an "error" (below) from cmake (2.6.1) about Intrinsics.gen but it seems to write out sln/vcproj anyway. Project.sln opens and builds OK (modulo a build error in llvmc2

On Sep 20, 2008, at 2:22 PM, Óscar Fuentes wrote: > IMHO, the CMake-based build system is almost complete enough to > replace > current MSVC++ project files (modulo some community review and > bug-fixing). Is this enough for adding it to the LLVM repo? Yes. >> From the point of view of a MSVC++ user, the new build system is >> trivial > to maintain: you can add a

Argiris Kirtzidis <akyrtzi at gmail.com> writes: > How does updating the CMake produced VC++ project files work ? > I mean: > > -I have CMake produce VC++ project files > -Compile the solution > -Do a svn update and pick up a couple of files > -Have CMake produce new project files > -Now, do I have to rebuild the entire solution again ? AFAIK, it should do the right

Óscar Fuentes wrote: > Argiris Kirtzidis <akyrtzi at gmail.com> writes: > > >> How does updating the CMake produced VC++ project files work ? >> I mean: >> >> -I have CMake produce VC++ project files >> -Compile the solution >> -Do a svn update and pick up a couple of files >> -Have CMake produce new project files >> -Now, do I have

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

On Mar 28, 2013, at 1:35 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: Oscar, just FYI, your wording is very strong, and that is often not the most productive way to make your point. That said, to address some of the things you've raised in a couple of threads: >> If you think these are irrelevant points then you need to state why >> and should back it up with less

>>> 1. Please send patches instead of full files. The best way to do this >>> is >>> to use CVS like this: 'cvs diff -u' in the directory that you care >>> about. You can also specify specific files to diff as well. >> >> Okay, I will do this in future, our posts crossed so I have not done that >> for the MASM backend. I will

Dmitri Makarov <nebraskin at yahoo.com> writes: >> Is it reasonable to ask > > Yes, it's reasonable. Since this is open source we depend on contributions from the community, etc... You know how the song goes. Seriously, I'll like to see a healthy MSVS build as much as you, but someone must do the work. > Moreover, I'd be content with a build system that

On Tue, 12 Jul 2005, Aaron Gray wrote: >> >> 1. Please send patches instead of full files. The best way to do this is >> to use CVS like this: 'cvs diff -u' in the directory that you care >> about. You can also specify specific files to diff as well. > > Okay, I will do this in future, our posts crossed so I have not done > that for the MASM

>> Here is a mod to X86 that allows GAS to be used with MS Visual C++. >> >> I introduces a 'forWindows' variable like 'forCygwin' in th >> X86SharedAsmPrinter class. >> > > A couple of comments: > > 1. Please send patches instead of full files. The best way to do this is > to use CVS like this: 'cvs diff -u' in the

On Tue, 12 Jul 2005, Aaron Gray wrote: >>> Right, presumably Wndows does not set the TT. Should Windows or MSVC++ >>> have one ? If so how do I go about it. Maybe Jeff should be involved ? >> >> It should/will. Currently there is no C/C++ front-end that works on native >> windows, but that doesn't really matter. In the future, we want to key off

Dear R users, Have you experienced any difficulty in calling R's ISNAN() from a C code? I have C codes including ISNAN() calls and they worked well until I upgraded my R from 1.7 to later versions. When I tried to compile the codes in the version 1.8 and 1.9, I got error messages like this: test.obj : error LNK2001: unresolved external symbol _isnan .\testR.dll : fatal error LNK1120: 1

Chris Lattner <clattner at apple.com> writes: > Ok. Killing off autoconf would be a huge bonus, but should probably > be done as a second step. My plan is a staged one: First, support MSVC++. Second, implement what `configure' does now. MSVC++ users would be the first ones to take advantage of this, instead of the current hack Visual Studio does. Finally, add capabilities

Óscar Fuentes <ofv at wanadoo.es> writes: >> It appears the Windows build has regressed over the past week. >> >> The build fails quite early (during the "Performing TableGenStep" >> phase). >> >> Any help/pointers would be appreciated. > > It breaks for me because the usage of INT64_C, which was introduced on > r57663 and 57668. >

Many thanks to the 23 people who took the time to respond to the survey. It really will help me spend my time more effectively. As promised, here are the results. I have inserted some comments inside [brackets]. 1. Have you downloaded wxRuby? YES 19 NO 4 2. Have you successfully built wxRuby? YES 14 NO 8 [We really need binary downloads so people don''t have to build anything.

Chris Lattner wrote: > On Tue, 12 Jul 2005, Aaron Gray wrote: > >>>>> Sure, but presumably you want to differentiate between nasm and >>>>> masm (if they are not compatible) right? >>>> >>>> >>>> Right >>> >>> >>> Then you need something more specific than 'isWindows'. I'd

Hi Eric, > From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs No. They are using Windows Platform ABI for almost everything (e.g. calling API, C runtime, etc.). At least mingw does. The differences are exactly in unspecified area (e.g. passing / returning structs by value). The only difference is C++, where mingw / cygwin follows Itanium ABI and MSVC - its

Full_Name: Byron Ellis Version: 1.2.2 OS: all Submission from: (NULL) (140.247.105.95) R_ext/Arith.h #ifdef MAIN #define extern #endif #ifdef __cplusplus extern "C" { #endif these two should be reversed. Its never a problem because builds aren't done against C++ compilers, but its still an error (just a low priority one). also, you could change that to #ifdef __cplusplus extern

>>>> Right, presumably Wndows does not set the TT. Should Windows or MSVC++ >>>> have one ? If so how do I go about it. Maybe Jeff should be involved ? >>> >>> It should/will. Currently there is no C/C++ front-end that works on >>> native windows, but that doesn't really matter. In the future, we want >>> to key off the target