64-bit windows version?

[Simon Marlow]

Peter Tanski wrote:
> 
> On Jun 22, 2007, at 11:42 AM, Simon Marlow wrote:
> 
>> Peter Tanski wrote:
>>> A bit invasive (it involves modifying the make rules so they take an 
>>> object-suffix variable).  Instead of the current suffix.mk:
>>> $(odir_)%.$(way_)o : %.hc
>>> it should be:
>>> $(odir_)%.$(way_)$(obj_sfx) : %.hc
>>> or some such.  This may affect other builds, especially if for some 
>>> reason autoconf can't determine the object-suffix for a platform, 
>>> which is one reason I suggested a platform-specific settings file.  I 
>>> could handle this by having autoconf set the target variable, put all 
>>> the windows-specific settings in a "settings.mk" file (including a 
>>> suffix.mk copy) and have make include that file.
>>
>> Surely this isn't hard?
>>
>> ifeq "$(TargetOS)" "windows"
>> osuf=obj
>> else
>> osuf=o
>> endif
>>
>> and then use $(osuf) wherever necessary.
> 
> Yes it is easy but now all Makefiles must be changed to use $(osuf), 
> such as this line in rts/Makefile:
> 
> 378: %.$(way_)o : %.cmm $(H_FILES),
> 
> for what will be a (hopefully) temporary Windows build.

I bet there are only a few makefiles that explicitly refer to "o" as the 
object-file suffix.

I don't understand why you see this as a temporary measure.  Surely we'll need a 
way to build GHC again for this platform?  Unless you intend to replace the 
whole build system?  (which I strongly recommend *not* doing, at least not yet)

>>>>  4. modify the core packages to use Win32 calls only (no mingw)
>>> That is where a lot of preparation is going.  This is *much* harder 
>>> to do from mingw than from VS tools since you have to set up all the 
>>> paths manually.
>>
>> I don't understand the last sentence - what paths?  Perhaps I wasn't 
>> clear here: I'm talking about the foreign calls made by the base 
>> package and the other core packages; we can't call any functions 
>> provided by the mingw C runtime, we can only call Win32 functions.  
>> Similarly for the RTS.  I have no idea how much needs to change here, 
>> but I hope not much.
> 
> To use the MS tools with the standard C libraries and include 
> directories, I must either gather the environment variables separately 
> and pass them to cl/link on the command line or I must manually add them 
> to my system environment (i.e., modify msys.bat, or the windows 
> environment) so msys will use them in its environment.
> 
> The other problem is the old no-pathnames-with-spaces in Make, since 
> that must be made to quote all those environment variables when passing 
> them to cl.  I could use the Make-trick of filling the spaces with a 
> character and removing that just before quoting but that is a real hack 
> and not very reliable--it breaks $(word ...).

Use GHC as your C compiler, i.e. don't invoke CL directory from make, and add 
the INCLUDE/LIB directories to the RTS's package.conf.

> Altogether it is a pain to get going and barely reproducible.  That is 
> why I suggested simply producing .hc files and building from .hc using VS.

Doing an unregisterised build, you mean?  Sounds a bit scary!

Cheers,
	Simon