64-bit windows version?

[Peter Tanski]

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.

>>>  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 ...).

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.

Cheers,
Pete