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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
