[LLVMdev] Files to lib/System/Win32

[Paolo Invernizzi]

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.