similar to: [LLVMdev] Win32 version of MappedFile.cpp

Actually, <algorithm> is not correct. This remove is in stdio.h and io.h in VC7.1. It removes a file, not elements from a collection. The proper solution is to not use remove at all and use Path::destroy_file(). On Fri, 24 Sep 2004 08:09:37 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > <algorithm> works too. > > On Fri, 24 Sep 2004 10:09:21 -0500 > Alkis

On Fri, 2004-09-24 at 08:17, Jeff Cohen wrote: > Actually, <algorithm> is not correct. This remove is in stdio.h and > io.h in VC7.1. It removes a file, not elements from a collection. > > The proper solution is to not use remove at all and use > Path::destroy_file(). Yes. I'm currently working on "Block", "File" and "MappedFile"

<algorithm> works too. On Fri, 24 Sep 2004 10:09:21 -0500 Alkis Evlogimenos <alkis at cs.uiuc.edu> wrote: > On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > > Jeff Cohen wrote: > > > > >But I compiled that under vc7.1 as it was! > > > > > > > > ;-(( > > > > Probably is an implicid includes, but I'm using the

Here's the patch to Signals.cpp. assuming that stdio.h is acceptable (can't imagine it won't work). On Fri, 24 Sep 2004 09:29:05 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > Uh... this may be a silly question, but why can't you include <stdio.h>? > It'd be much better than <iostream>. > > Anyway, I think I'll try this weekend to come

Sigh... take it up with Microsoft. On Fri, 24 Sep 2004 12:06:36 -0500 Misha Brukman <brukman at uiuc.edu> wrote: > On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > > (can't imagine it won't work). > > We prefer #include <cstdio>, since this is C++ after all. :) >

Uh, use this version instead... (It's way past my bedtime :)) On Thu, 16 Sep 2004 01:05:52 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > Here's the free-of-copyrighted-Microsoft-code version of Signals.cpp. > > Actually, I'm not sure if the original would work on NT/2000/XP. It was doing > stuff that's only supposed to be done on Win95/98/ME. >

Uh... this may be a silly question, but why can't you include <stdio.h>? It'd be much better than <iostream>. Anyway, I think I'll try this weekend to come up with my own way of building on Win32. I prefer that building on Windows depends only on Microsoft and GNU tools, and the fewer of the latter the better. My gut instinct is to capture all the files generated by

Patch for Signals.cpp attached. On Sat, 18 Sep 2004 21:30:12 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Sat, 18 Sep 2004 12:30:41 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > Patch looks good so I committed it. I'd be interested in knowing what > > your test results are once you start testing with the Win32 port. > > I tested

Completed testing. Diffs for Path.cpp attached to fix bugs. Some of them are probably present in the Unix version as well. There are some uses of ThrowError when there is no error present in errno to format. A throw statement should be used. Path::is_valid uses realpath on Unix. The problem is that realpath validates that all the directory components of the path actually exist and are

>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Mon, 13 Sep 2004 21:24:47 -0700 > > >But there are some issues with System I'm going to have to take care of >besides using Win32. There appears to be some Unix assumptions like the >presence of /etc or the HOME environment variable. Neither have any >true equivalent in Windows. > Will be fixed in a working

>From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> >Date: Tue, 14 Sep 2004 18:10:29 +0200 > >>From: Jeff Cohen <jeffc at jolt-lang.org> >>Date: Tue, 14 Sep 2004 07:25:11 -0700 >> >>On Tue, 14 Sep 2004 12:46:31 +0200 >>"Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: >> >> > >From: Jeff Cohen

It would be great to avoid STLPort and use plain vanilla VC... as I told, the biggest difference it's how the hash_map and hash_set are implemented, but I'm not so strong in C++ for resolving the iussue. About the build procedure, it's based on scons, and it's still at a very preliminary stage... Right now I'm trying to build TableGen with it, as till now I've always

Hi Jeff, Typically, I've found out that these missing functions are placed beneath lib/System/Unix in some of *.cpp files. These function can be copied to their respectively lib/System/Win32 *.cpp files. Henrik. ----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at

On Tue, 14 Sep 2004 12:46:31 +0200 "Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: > >From: Jeff Cohen <jeffc at jolt-lang.org> > >Date: Mon, 13 Sep 2004 21:24:47 -0700 > > > > > >But there are some issues with System I'm going to have to take care of > >besides using Win32. There appears to be some Unix assumptions like the

Here's the Win32 version of Signals.cpp. -------------- next part -------------- A non-text attachment was scrubbed... Name: Signals.cpp Type: application/octet-stream Size: 20861 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040915/d3b43059/attachment.obj>

Patch committed. Thanks for cleaning up some of the coding standards issues. Reid. On Sat, 2004-09-18 at 22:18, Jeff Cohen wrote: > Patch for Signals.cpp attached. > > On Sat, 18 Sep 2004 21:30:12 -0700 > Jeff Cohen <jeffc at jolt-lang.org> wrote: > > > On Sat, 18 Sep 2004 12:30:41 -0700 > > Reid Spencer <reid at x10sys.com> wrote: > > > >

>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Tue, 14 Sep 2004 19:43:34 -0700 > >OK, I stand corrected: mingw can be used to create honest-to-goodness >Windows applications using Win32. But you're still using it as a Unix >emulator :) > OK, if POSIX.1 is unix emulation then we have that all *nix emulates all *nix and that's fine with me :) OK, I admit,

>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Wed, 15 Sep 2004 10:35:36 -0700 > >What's a "compiling mesh?" What I meant, was that there are some implicit defines in mingw (like __GCC) and vcX (like _MVC) but possibly also other unsupported? internal structures. As I stated earlier mingw should be win32 api compliant, but not for complicating matters. But

>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Tue, 14 Sep 2004 07:25:11 -0700 > >On Tue, 14 Sep 2004 12:46:31 +0200 >"Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: > > > >From: Jeff Cohen <jeffc at jolt-lang.org> > > >Date: Mon, 13 Sep 2004 21:24:47 -0700 > > > > > > > > >But there are some

I think the $HOME and /etc assumptions are very limited in nature. Most of us who use LLVM every day here at UIUC don't need to bother installing anything in $HOME or /etc, and so they shouldn't be considered a major stumbling block for building a version of LLVM that runs on Windows, no matter how it is done or what libraries it is linked with. Making it possible to build LLVM on