64-bit windows version?

[Peter Tanski]

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:
<compile/link command> <compile/link flags> <output> <source/object  
files> <other flags>
while for cl running link.exe or link.exe, it is better to put all  
the files at the end of the command line:
<compile/link command> <compile/link flags> <output> <other flags>  
<source/object files>

It also adds one more layer of indirection a that delicate stage.

I am in the process of modifying and testing changes to some of the  
build rules for cl.  As an added bonus, unless you want to keep debug  
information in each object file (instead of a separate .pdb file), by  
putting compile options and sources into a compile/link file we:
(1) avoid problems of exceeding the command line; and,
(2) have the option to use /Gm, which does automatic dependancy  
tracking for us.

While I am at it, back in November 2006 I mentioned removing the old  
mingw/cygwin-dll stuff.  I can leave that in for now until Windows- 
native is done.  I keep coming across greencard stuff and honestly  
that is annoying since greencard hasn't been supported since GHC  
6.2.  I would really like to remove it entirely but I don't know  
whether you want to keep it in.

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