64-bit windows version?

[skaller]

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