On Jun 21, 2007, at 4:16 AM, Simon Marlow wrote:
Peter Tanski wrote:
skaller wrote:
Why do you need mingw? What's wrong with MSVC++? The largest problem is the build system: GHC uses autoconf with custom makefiles.
So autoconf won't work with MSVC++, that is indeed a problem. But this doesn't mean we have to stop using Makefiles and GNU make - the rest of the build system will work fine, provided it's told about the different conventions for names of object files etc. I don't see a compelling enough reason to stop using GNU make. The build system doesn't even need to invoke CL directly, since we can use GHC as a "driver" (isn't this the way we agreed to do it before?).
We use autoconf in a pretty limited way (no automake), so I don't think it will be hard to work around, even if we have to just hard- code all the configuration results for Windows.
The make system does work well and must be kept in order to port GHC to a new posix platform--too many parallel projects (pun intended) work with the current system. I have not kept a good count of monthly configuration-based bugs but there are at least a few a month, for known platforms, including OS X (a significant user base) and Mingw. If I could change one feature of the current system I would set up a wiki page with specific build requirements (I mean location, program/library with function declaration), and for known systems use autoconf only to determine what the $(build) system is and to ensure those programs are available, then jump into make which would call pre-set configuration makefiles for that system. I spent a good amount of time writing the replacement library build system in GNU Make (min. 3.8--the current min is 3.79.1) to blend seamlessly with the current system. It does use a custom "configure" script written in Python (more consistently portable, no temporary files of any kind in $(srcdir))--John, that is where I originally used Interscript: to bake configuration settings into the setup files. The configuration determines what system it is on and the relative-path location of certain requirements if they are not already available--for testing the processor type and os support (when it can't read from something cool like /proc/cpuinfo) it does build small programs but all building is done in the build directory which may be located anywhere you want. It then sets those parameters for configuration files that already contain other presets for that platform; general guesses may go into the main GHC autoconf and I will keep them very simple (new architectures get the generic C library by default). I simply can't convince myself that it is better to use a guess-based system for architectures I already know, especially when it also makes cross-compiling more complex than necessary. For Windows it uses a VS project and calls that from a DOS-batch file (for setup parameters) so you can run it from the command line. What I hope you would agree on for Windows-GHC is a build that ran parallel to the autoconf-make system. Of course that would require some maintenance when things change in the main system but I could write update scripts for trivial changes; I believe anything more complex should be carefully checked in any case. VS is troublesome (its project files are written in XML, but that may be automated). If you would rather use a Make-like system I could do it in Jam and then you would add only a few extra Jamfiles to the current system. As a bonus either VS or Jam would reduce build times, especially re- build times, would and probably reduce the number of configuration bugs we see around here. I would not suggest CMake, SCons or WAF; John wisely advised against anything invasive. Cheers, Pete