64-bit windows version?

skaller skaller at users.sourceforge.net
Fri Jun 22 10:18:11 EDT 2007


On Fri, 2007-06-22 at 14:45 +0100, Simon Marlow wrote:
> skaller wrote:

> > This misses the point. The 'suck it and see' idea fails totally for
> > cross-compilation. It's a special case.
> > 
> > The right way to do things is to separate the steps:
> > 
> > (a) make a configuration
> > (b) select a configuration
> > 
> > logically.
> 
> Hmm, I don't see how the approach "fails totally" for cross-compilation.  You 
> simply have to create the configuration on the target machine, which is exactly 
> what we do when we cross-compile GHC.  Admittedly the process is a bit ad-hoc, 
> but it works.

But that consists of:

(a) make a configuration (on the target machine)
(b) select that configuration (on the host machine)

which is actually the model I suggest. To be more precise, the
idea is a 'database' of configurations, and building by selecting
one from that database as the parameter to the build process.

The database would perhaps consists of 

(a) definitions for common architectures
(b) personalised definitions

You would need a tool to copy and edit existing definitions
(eg .. a text editor) and a tool to 'autogenerate' prototype
definitions (autoconf for example).

What I meant failed utterly was simply building the sole
configuration by inspection of the properties of a the
host machine (the one you will actually build on).

That does work if

(a) the auto-dectect build scripts are smart and
(b) the host and target machines are the same

BTW: Felix has a 4 platform build model:

* build
* host
* target
* run

The build machine is the one you build on. Example: Debian
autobuilder.

The host is the one you intend to translate Felix code to
C++ code on, typically your workstation. In Windows environment
this might be Cygwin.

The target is the one you actually compile the C++ code on.
In Windows environment, this might be WIN32 native (MSVC++).

The run machine is where you actually execute the code.

The 'extra' step here is because it is a two stage compiler.
Some code has to be built twice: for example the GLR parser
elkhound executable runs on the host machine to generate
C++ and it uses a library. The same library is required
at run time, but has to be recompiled for the target.
EG: Elkhound built on cygwin to translate grammar to C++,
and Elkhound on MSVC++ for the run time automaton.

I'm not sure GHC as such need cross-cross compilation model,
but bootstrapping a cross compiler version almost certainly does.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


More information about the Glasgow-haskell-users mailing list