64-bit windows version?
p.tanski at gmail.com
Mon Jun 25 11:43:18 EDT 2007
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;
(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
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>
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.
More information about the Glasgow-haskell-users