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