Yes, it should. I haven't reviewed Henrik's change set yet but if it doesn't look like clean Win32 code then I will create a separate target named MingW and adjust the configure script accordingly. On the other hand, no one has submitted any Win32 patches yet, so first come first served :) Reid. On Mon, 2004-09-13 at 19:35, Jeff Cohen wrote:> Uh... shouldn't a Win32 port use the Win32 API? > > On Tue, 14 Sep 2004 02:11:51 +0200 > "Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: > > > Hi > > > > Here is my first patches to the Win32 platform. > > > > They compile on the mingw platform. > > > > I haven't test them yet, but I thought it will best to put them in the save, > > just in case... > > > > > > /Henrik > > > > _________________________________________________________________ > > F_ alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/ > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040913/e43c5232/attachment.sig>
It isn't Win32 code at all. It depends on Unix emulation. Oh, all right. I'll take a crack at it. I'm an experienced Windows programmer (but I was programming Unix before Windows even existed). I was tempted to volunteer but Henrik beat me to it and anyway I'm not sure if I can afford to spend the time required to do this. It's not just System/Win32. To properly build on Windows it is bad form to use anything other than Microsoft's Visual Studio. Even using makefiles is frowned upon (well, considering Microsoft's offering of "nmake"...). And "configure" is right out. 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. And then there's the gcc front end... gcc cannot be bootstrapped using Microsoft's compiler or a non-Unix-like environment. It may not be possible at all to do a proper Windows port of the front end. The Windows ports of gcc generally pretend they're running on Unix. Anyway, I'll start and take a closer look at System. At least I'll be building LLVM on my fast computer :) On Mon, 13 Sep 2004 20:54:57 -0700 Reid Spencer <reid at x10sys.com>wrote:> Yes, it should. I haven't reviewed Henrik's change set yet but if it > doesn't look like clean Win32 code then I will create a separate target > named MingW and adjust the configure script accordingly. > > On the other hand, no one has submitted any Win32 patches yet, so first > come first served :) > > Reid.
Jeff, These are all reasons why the Win32 port doesn't exist today. LLVM is heavily influenced and implemented by Unix tools/concepts/facilities. Since building on Win32 will also be a problem, I think that we should just target cygwin as our Win32 solution for now and get that to work really well. I know cygwin is a slow pig, but at least we can get LLVM to work with it. We also have Interix which is another interesting approach. However, I don't think Interix has the tool support that we need to build LLVM, its just a Unix interface for windows machines, isn't it? I agree that if/when the time comes to support Win32 natively, it will be a big job involving configuration, new makefiles and project files, and all the other Visual studio shebang. I'm personally not up to that task as my Win32 skills are ancient and I have no interest in updating them. So, my $0.02 worth on this is that we ought to just leave the Win32 port alone for now. Most of us have Unix or cygwin and that works fine. When LLVM gets nearer to commercialization it will become someone's JOB to port it to Win32 at which time that will happen fairly rapidly. I'm not saying "don't do it". If you have the time, by all means, it would be VERY valuable. However, for now, it would also be valuable to just have you validate the cygwin build regularly. Make sense? Reid. On Mon, 2004-09-13 at 21:24, Jeff Cohen wrote:> It isn't Win32 code at all. It depends on Unix emulation. > > Oh, all right. I'll take a crack at it. I'm an experienced Windows > programmer (but I was programming Unix before Windows even existed). I > was tempted to volunteer but Henrik beat me to it and anyway I'm not > sure if I can afford to spend the time required to do this. > > It's not just System/Win32. To properly build on Windows it is bad form > to use anything other than Microsoft's Visual Studio. Even using > makefiles is frowned upon (well, considering Microsoft's offering of > "nmake"...). And "configure" is right out. > > 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. > > And then there's the gcc front end... gcc cannot be bootstrapped using > Microsoft's compiler or a non-Unix-like environment. It may not be > possible at all to do a proper Windows port of the front end. The > Windows ports of gcc generally pretend they're running on Unix. > > Anyway, I'll start and take a closer look at System. > > At least I'll be building LLVM on my fast computer :) > > On Mon, 13 Sep 2004 20:54:57 -0700 > Reid Spencer <reid at x10sys.com>wrote: > > > Yes, it should. I haven't reviewed Henrik's change set yet but if it > > doesn't look like clean Win32 code then I will create a separate target > > named MingW and adjust the configure script accordingly. > > > > On the other hand, no one has submitted any Win32 patches yet, so first > > come first served :) > > > > Reid. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040913/3a179ff3/attachment.sig>
On Mon, 13 Sep 2004 20:54:57 -0700 Reid Spencer <reid at x10sys.com> wrote:> On the other hand, no one has submitted any Win32 patches yet, so first > come first served :) > > Reid.Consider this a down payment :) The Win32 version of Memory.cpp attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: Memory.cpp Type: application/octet-stream Size: 1987 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040914/3b791809/attachment.obj>
On Tue, 14 Sep 2004 08:02:10 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote:> On Mon, 13 Sep 2004 20:54:57 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > On the other hand, no one has submitted any Win32 patches yet, so first > > come first served :) > > > > Reid. > > Consider this a down payment :) The Win32 version of Memory.cpp attached.On further reflection, I think we need to abstract the operation of throwing a formatted OS error message. This is done in many places, and the Windows way of doing it differs substantially from Unix. Basically take the ThrowError function and turn it into Process::ThrowOSError or something like that.