On Wed, 2007-06-20 at 11:39 -0400, Peter Tanski wrote:
The largest problem is the build system: GHC uses autoconf with custom makefiles.
Well, that needs to be fixed. Autoconf and make are rubbish.
I have looked into porting the whole thing to a Visual Studio project, using SCons (unreliable), CMake (limited command line abilities--good for a one-shot build but really just a "safe" lowest-common-denominator version of Make), Waf (another python-based build system that started as a fork of SCons for the KDevelop changeover from Autotools) and Jam. I would prefer to use Jam but I'm afraid I would be the only one who would ever want to support it. Nothing has the auto-configuration abilities you (John) built into the Felix Interscript-based system but I do not porting the build system (at least) to Interscript would go over well with anyone else who wanted to maintain it and the build itself would require heavy customisation.
The Felix build system is more or less independent of Interscript. There's NO WAY GHC should be ported to use Interscript. We don't want to touch any of the source files. For information of other readers: Felix uses two pieces of advanced technology for building. 1. Interscript is a general purpose extensible literate programming (LP) tool. The idea of LP is that code is embedded in documents. Interscript documents are *.pak files, which when 'tangled' create the actual sources. Interscript is different to other LP tools in that you can embed arbitrary Python script inside a document and use it to *generate* code (or documentation). This just wipes out rubbish like autotools method of filling in Makefile.am templates because it is (a) programmatic and (b) applies to all sources the same way. I regularly use tables to generate various parts of a program, eg a list of tokens to generate lexing components as well as a pretty printing function. But LP is an invasive technology. You pay for using it: it pervades the whole software base and it typically defeats IDE's and syntax colouring etc. 2. The Felix build system is basically a 'debian like' package manager. Although it hooks interscript, that's just another plugin of the build system. The key thing for the building portability is that the C and C++ compilers are represented by Python classes. There is a pre-programmed class for gcc, and another for MSVC++. The way this works is we have identified build abstractions like: * make an object file for static linking * make an object file for dynamic linking (-fPIC thing) * make a dynamic link library from object files * make a static link library from object files * static link a program * link a program for dynamic loading plus some things peculiar to Felix. Each of these functionalities is represented by a method of the Python class. So the build scripts are portable, provided you use these methods on an object of the appropriate compiler class (gcc or msvc). Similarly, to manage files, scripts say stuff like: fileparts = string.split(filename,"/") osfilename = string.join(fileparts,os.sep) which converts a 'unix' filename to your local OS convention. I typically mandate Unix style filename literals even on Windows, but it is tricky to get this right. To build a library a package typically has a meta-description, which is itself an executable Python script which is requires to set some variables, such as a list of source files to be compiled. The build system compiles them using both the static and dynamic methods, and makes both shared and static archive libraries. Clearly GHC will have different requirements to Felix. I'm not suggesting copying the Felix build system verbatim! What I actually recommend is: (a) Pick a portable scripting language which is readily available on all platforms. I chose Python. Perl would also do. I can't recommend Tcl, it's too messy. Scheme may be an excellent choice I'm only just learning it and I'm not sure about availability, but it seems really well suited if you can hack all the brackets :) (b) Write the WHOLE build system using that language. For parts that differ between OS, you use parameters. These parameters can be simple things like EXE_EXT = ".exe" # Windows EXE_EXT = "" # Unix etc, or they can be classes encapsulating complex behaviour. Too much abstraction is bad .. environments are too quirky, lots of cases with minor variations is the way to go unless you're REALLY sure what you have is an abstraction. (c) provide 'values' for the parameters for the platform combinations you want to build on (d) write configuration scripts to create a file of these parameters -- if that fails the user can edit it. You can also supply 'prebuilt' configurations for common platforms. BTW: doing all this was more or less mandatory for Felix, since it is a cross-cross-compiler. The Felix build system actually splits building into 'phases' where each phase can be executed on a distinct machine (with a shared file system). These phases 'split' all the packaged components into time slices, and the build process builds the packages in dependency order for each slice in turn. This is useful on Windows, eg use Cygwin to build some of the tools, but use them in native windows shell to build the next stage. Since GHC is bootstrapped it will be even messier.. :)
There is also some gcc-specific code in the RTS (inline assembler, use of extern inline, etc.)
MSVC++ for Vista and beyond does not allow any inline assembler. This is probably because it wants to target x86, x86_64 and also ia64 (as well as CLR).. and doesn't have gcc "interesting" way of managing register usage.
I don't know of any completely free 64-bit compilers for Windows.
I don't know of any completely free 64 bit compilers for Linux. gcc is GPL which is anything but free of encumberance .. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net