On Jun 25, 2007, at 5:19 AM, Simon Marlow wrote:
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.
After poking around I found that my fears were unfounded. Simply pass cl the /TC (or -TC) option--same as the gcc option '-x c'. Object files are also fine since cl assumes any file with an unrecognised suffix is an object file. The environment variables problem is also solved: either have the environment set up automatically by placing a batch-script 'call' to the MS PSDK 'SetEnv.Cmd' before the shell login in msys.bat or start the DOS shell from the MS PSDK shortcut and log into the msys shell manually--or run the whole thing from DOS. Shows how much I know of msys. Passing flags to cl would be best in a command file (at least I have done _that_ before).
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)
I keep on referring to this as temporary because there are two different builds here: (1) the build using the old mingw-GHC, without option support for CL; and, (2) the build using the new Windows-native GHC. You will almost certainly keep mingw-GHC around but users should not have to download a mingw-GHC to build Windows-native from source (they can't start at a stage1 build), so the Windows-native requires a separate setup. That might as well be Windows-native itself, in other words, use VS--it is the quickest and easiest build to put together. I do not suggest CMake because CMake is a sledgehammer when it comes to managing projects and sub-projects: all paths are absolute (you cannot move the source directories around), there is only one major "Project" in a system--it only really builds 'all', not sub-targets and build variants beyond the buitin Debug, MinSizeRel, Release, etc., have to be custom-added; it would not integrate well with the current $(way) system. If you are heavily against using VS, maybe an Eclipse/Ant-based build would do. I might use Bakefile. It would be much better to have a single build system. I would gladly replace the whole thing for three reasons: (1) it is a source of many build bugs and it makes them much more difficult to track down; and, (2) it seems to be a serious hurdle for anyone who wants to build and hack on GHC--this is true for most other compiler systems that use the autoconf and Make; and, (3) if GHC is ever going to have cross-compilation abilities itself, the current build system must go, while cross-compiling GHC with the current system requires access to the actual host-system hardware. The reasons I don't are: (1) time (parallel to money); (2) I wouldn't undertake such an effort unless we were all pretty sure what you want to change the build system to; (3) an inevitable side-effect of the move would be loss of old (or little-used) build settings, such as GranSim, and a change to the build system would propagate to parallel projects; and, (4) it is a huge project: both the compiler and libraries must change and the change must integrate with the Cabal system. Work on the mingw-make system is progressing fairly well. The reason to make a special VS build are: (1) Windows programmer familiarity; (2) reduction in the number of build bugs; (3) ease of extension or integration with other VS tools, such as .NET; and, (4) speed--VS builds are much faster than Make. I should also add that when building the RTS it is simply much easier to have a build problem reported in VS than search back through Make- output and manually go to the offending line in a source file. The reason not to make a special VS build is you would have to support it--one more thing to check when new source files are added. As I said before, this may be scripted and if Windows programmers have something familiar to work with there may be more of them to help. (You probably have better reasons than that one.)
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.
Certainly doable but it does present a conundrum: for the old GHC
(without builtin cl-support) the order for compilation seems to be:
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!
It would be difficult but it would completely remove the mingw-ghc from the build process and it would stress-test the resulting cl- compiled haskell code. Cheers, Pete