64-bit windows version?
simonmarhaskell at gmail.com
Mon Jun 25 05:19:53 EDT 2007
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"
>> 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
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!
More information about the Glasgow-haskell-users