Hi
What did I start? <*shrug*>
Well, well, well.
First a little bit of history:
I joined the LLVM project, because the ideas sounded very interesting to me and I voluntered for a minor patch for prefetch datasupport for the gcc-compiler.
At that time, when I joined, the only possibility to develop on the windows platform was to use Cygwin Unix Windows emulation layer, but it had some caveats, so it wasn't considered to be functional and no one seemed to iron these out. And to me these seemed to be very hardcore and very Cygwin specific.
Personally, I don't like cygwin, mainly because of the automatic and self-composed package/installation procedure/program and my experinces with cygwin was, that if you don't have directly internet access, it's really a painfull process to download, install and upgrade.
And at that time when I started at this project, my access to the internet was only a 56k buad dial-up connection through my private ISP.
However, through my job I had access to download a complete selfcontained installation of Microsoft's/Interop's Services for UNIX 3.5 (SFU/Interix) POSIX.1 windows subsystem. To upgrade the platform was not as painfull as for Cygwin. Furthermore, Interix is not a Windows emulation layer, but a truely self contained subsystem running unix programs together with windows. At that time it seemed to me, that it was a feasible way to have LLVM running on windows. However, I've ran into trouble with flex not generating correct state tables on my local system (though the SFU support is able to generate correct state tables on their test machines) for the tablegen tool. Furthermore, my experiences for now with Interix are, that it's not as compatible with UNIX as I thought.
I'm not an experienced UNIX/Linux user (although, for a long time ago I've been programming on a DEC Ultrix system), but I want to be it again. That is why I started on a port for Interix and that's why I didn't stop, when you guys told me to do so. Futhermore, I'm a seasoned C++ programmer but have a lot experinces with windows development in general with VB and -Script, ASP and you name it.
When Reid started the lib/System project I volunteered to do a Win32 port, mainly because, as far I could see on the LLVMdev list, no one seemed to be interested to do get LLVM working on windows other than through cygwin.
With the experiences from the Interix port, I realised, that a port to Native Win32 will be a long a painfull process that should/has to be divided up in smaller steps than one giant leap. I started again looking on other unix like windows platforms and came across MinGW.
As far as I know uptil now (correct me, if I'm wrong) supports MinGW truely the Win32 API through their own port of gcc and header files. Furthermore, MinGW is POSIX.1 compatible at the source code level and MSYS command shell. In this respect, MinGW seems to be another unix like system, but it generates truely self contained windows executables without any emulation and in my view a good Win32 candidate for the first step of many. The MSYS shell understands BASH scripts, so the configuration and compilation of llvm seems to work out-of-the-box without further modifications, although I've experienced some caveats. And this is one of the small steps we/I have to make before getting a fullblown Win32 port.
In the end of the Win32 port we should have a completely self contained installation of LLVM environment, before windows users will jump on the wagon.
Only time will tell if LLVM tools compiles with VC.
But, if you guys think it is a bad idea to start a win32 port in small steps from a truely win32 compatible platform, feel free to tell. No harm is done and I'll install cygwin (because, today I've direct internet access at home) and start hacking my little prefetch data project <:)
Of course, when the Interix support turns back with a solution to the flex state table generation, I'll continue on that platform too, if you guys still want it.
From: Chris Lattner <sabre@nondot.org>
Date: Tue, 14 Sep 2004 00:50:43 -0500 (CDT)> 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.
True
> 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.
True, that should be the approach for now.
> 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?
Interix has all the tools for unix development and more.
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.
MinGW seems to support this requirement.
> 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.
We don't yet have tools to support automatic generation of at least nmake makefiles. If we did, the road was a bit more feasible with VC.
> I'm personally not up to that
> task as my Win32 skills are ancient and I have no interest in updating
> them.
Uhhhmmmm, why not 
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?
I agree with Reid, when porting to Win32 and VS projects, I don't think it will be a huge task to maintain, if we get some tools to generate nmake or vs projects for us.
Moreover, Paolo, will hopefully give us/me some valuable insight into a VS port with the HowToUseJIT example.
Henrik