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>
On Sep 14, 2004, at 12:52 AM, Reid Spencer wrote:>> 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)Eww. Come now. C:\Program Files\Low Level Virtual Machine\Configuration :-) -Brian
On Tue, 14 Sep 2004 01:01:46 -0500 "Brian R.Gaeke" <gaeke at uiuc.edu> wrote:> > On Sep 14, 2004, at 12:52 AM, Reid Spencer wrote: > >> 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) > > Eww. Come now. C:\Program Files\Low Level Virtual Machine\Configuration > > :-) > > -BrianOnly for global settings. For per-user settings, it would be C:\Documents and Settings\<user>\Application Data\Low Level Virtual Machine\Configuration and as Application Data is a hidden directory, we can protect the integrity of the configuration settings from the unwashed masses. So, am I joking or am I serious :) Of course, there's always the registry...
On Mon, 13 Sep 2004 22:52:59 -0700 Reid Spencer <reid at x10sys.com> wrote:> 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.The breakage will come from stuff like new files being added. The UNIX makefiles are updated, but the VS project files (or even Windows makefiles) are not. Or C++ code is written that Microsoft's compiler objects to. At least you're not using the native compilers on the propriety UNIXes. Trust me, that is a wise decision.
On Sep 14, 2004, at 7:52 AM, Reid Spencer wrote:> 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.I'm the last person who can raise his hand and speak about the LLVM project but... I feel you are totally right. IMHO there's a big difference between aiming to port the whole framework to Windows and porting only the very-core-stuff (TM;) Porting the using-the-jit example, have to be trivial in the sense that you must be able to use the core-stuff in such an easy way, apart from platform differences. MinGW is a more radical (and efficient) port of the gnu compiler to win32. It does not require any cygwin.dll and try to rely less on emulation. It's distributed with a minimal bash support and common *nix tools. Actually I feel that is probably more difficoult to adapt LLVM to it, but not SO different to the cygwing port. Summa summarum it has the advantage of producing standalone executable without external dependencies.> 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.I think that MinGW is a better alternative to cygwin on windows....> I think this is where we use cygwin which has already been shown to > work > with our makefiles.Also with MinGW you have all the build tools chain... but alas, someone must try it ;-) That told, building the LLVM with the microsoft compiler is another matter. I'm interested in building the backend, not the frontend tools (hoping to skip a lot of problem related to signal-paths-and-portability-mess), because I want to play with the 'compiler-infrastructure'. Actually the MS C compiler is a GOOD compiler, very compliant and efficient, and has the BIG advantage that is compiles with the defacto-standard MS C runtime... I'm very busy in these days... but I hope to send other VC patches soon. --- Paolo Invernizzi PS... regarding the maintenance of Visual Studio projects, I'm using scons (www.scons.org) instead of make. It keeps them updated and turns happy the IDE afecionados and the command-line guys.