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>
I don't know anything about Interix. It may be best to defer a true Win32 port. It's not just the time it would take to do it, it's the time to keep it up to date as LLVM evolves. The Win32 port will constantly break, and I don't have the time to keep fixing it. I've got my own time-consuming projects :) That said, the architectural issues should still be addressed. What does LLVM expect to keep in /etc/llvm and where would it keep it on Windows? How will it handle the Windows custom of having spaces in file and directory names? (GNU make hates it.) Why would it need to know the user's "home" directory? That sort of stuff. I don't have cygwin or any other Unix emulator on my Windows system, so I couldn't do validation. I do my Unix programming on Unix :) On Mon, 13 Sep 2004 22:22:34 -0700 Reid Spencer <reid at x10sys.com> wrote:> 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, 13 Sep 2004, Reid Spencer wrote:> These are all reasons why the Win32 port doesn't exist today. LLVM isWell, the reason it doesn't exist today is that noone has worked on it. :)> 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 sorta agree, but not entirely. In particular, I think that it's reasonable for LLVM as a whole to require cygwin. However, I think that it would be great (and doable) to be able build the LLVM tools WITHOUT linking to the cygwin DLL or using any of the emulation code. This should provide fast executables without having to change all of our support makefiles and other stuff.> 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.I really am not sure whether it would make sense to do the full VS project thing. In particular, it would be hard to maintain. Porting lib/System to use native win32 sounds like an excellent idea though, and IS quite useful. Thoughts? -Chris -- http://llvm.org/ http://nondot.org/sabre/
On Tue, 14 Sep 2004 00:50:43 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote:> On Mon, 13 Sep 2004, Reid Spencer wrote: > > > These are all reasons why the Win32 port doesn't exist today. LLVM is > > Well, the reason it doesn't exist today is that noone has worked on it. > :) > > > 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 sorta agree, but not entirely. In particular, I think that it's > reasonable for LLVM as a whole to require cygwin. However, I think that > it would be great (and doable) to be able build the LLVM tools WITHOUT > linking to the cygwin DLL or using any of the emulation code. This should > provide fast executables without having to change all of our support > makefiles and other stuff.There's a legal reason to avoid cygwin... Unless you cough up money, it's GPL--and not LGPL.> > > 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. > > I really am not sure whether it would make sense to do the full VS project > thing. In particular, it would be hard to maintain. Porting lib/System > to use native win32 sounds like an excellent idea though, and IS quite > useful.Well... it wouldn't be the end of the world to use GNU make. /Some/ GNU software would be required, bison if nothing else. Still would need a Windows-specific set of makefiles. They could be based on the makefiles generated by configure.> > Thoughts? > > -ChrisYes, I did just have another thought :) The Win32 port would be pointless unless it can produce Windows executables, especially GUI apps. LLVM would have to be able to handle Windows.h and friends, and some way of converting the assembly files produced by llc into binaries. Ideally, without using GNU as or ld.> -- > http://llvm.org/ > http://nondot.org/sabre/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
On Mon, 2004-09-13 at 22:38, Jeff Cohen wrote:> I don't know anything about Interix. > It may be best to defer a true Win32 port. It's not just the time it > would take to do it, it's the time to keep it up to date as LLVM > evolves. The Win32 port will constantly break, and I don't have the > time to keep fixing it. I've got my own time-consuming projects :)Actually, I don't expect that the Win32 will constantly break once the bulk of LLVM is converted over. LLVM needs precious little support from the operating system. A few fork/exec here, a little mmap there, and some file/path support. That's about it. It may grow overtime, but if we're using a lot of the operating system interface (any operating system interface), we're doing something wrong.> That said, the architectural issues should still be addressed.I agree. Chris made a good point in that there shouldn't be anything wrong with using cygwin for the build tools but compiling our libraries so that they make use of native windows calls rather than requiring the slow cygwin.dll. That would make our tools work much better on windows and it would not be terribly difficult to do.> What > does LLVM expect to keep in /etc/llvm and where would it keep it on > Windows?I expect this would just be in the Windows directory (C:\WINNT or C:\WINDOWS). It *could* keep the configuration files for llvmc and anything else that uses configuration files in that directory. However, the likely place for these would be the llvm installation directory. I might drop the notion of "special paths" in the sys::Path interface and just replace it with "FindConfigFile" which would do the right thing on a given platform.> How will it handle the Windows custom of having spaces in file > and directory names? (GNU make hates it.)I think this is where we use cygwin which has already been shown to work with our makefiles.> Why would it need to know the user's "home" directory?This is to allow the user to override the installed configuration file settings for llvm. Again, we shouldn't expose the concept of "home directory". Instead we should expose "FindConfigFile".> > I don't have cygwin or any other Unix emulator on my Windows system, so > I couldn't do validation. I do my Unix programming on Unix :)Can't blame ya! Thanks, Jeff. Reid. -------------- 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/90233e25/attachment.sig>