64-bit windows version?
p.tanski at gmail.com
Fri Jun 22 13:37:19 EDT 2007
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.
>>> 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
More information about the Glasgow-haskell-users