[MLton-devel] Questions for Win32 port
Stephen Weeks
MLton@mlton.org
Thu, 31 Oct 2002 09:11:31 -0800
The easy one first.
> 2) I tried doing some of the "usual" modifications
> to the include files and then do a normal Linux
> native make and make install. But my modified
> header files didn't seem to get installed
> (at least not in /usr/lib/mlton). Are they
> installed somewhere else when I'm compiling from
> source compared to when I just installed the binary?
If you look at the main Makefile, the install target by default now
puts everything in the "install" directory of the sources. If you
want to put the install somewhere else, you need to set the DESTDIR
variable.
> 1) How am I supposed to set up the boot-strap process
> when building a cross-compiler?
Here are the steps in building a new MLton cross compiler, and then a
native compiler on the new machine if you want (it's certainly a good
test of the cross compiler to do so).
* Build a gcc cross compiler for your target. You may find
build-cross-gcc useful for this. After this, you should be able to
call gcc with the new host via "gcc -b <cross-host>", where
<cross-host> is the name of the host type. For example, with
cygwin, this is i386-pc-cygwin. Since you're building a MinGW cross
compiler (I think), I'll use i386-mingw in this example.
* Port the runtime system. This means making patches until you can
successfully do "make HOST=i386-mingw" in the runtime directory.
Hopefully, your job will be made easier by all of the #ifdefs that
have a default clause with an #error macro. You will at least need
to fill in all these, either by adding an "|| defined (__MINGW__)"
to an existing clause or by adding an new "#elif (defined
(__MINGW__))" clause. Please leave the #else #error in place for
future ports.
One thing that you will have to do is add a new MLton_hostType
constant in basis-constants.h. Just pick the next available one,
which is currently 3. You will use this later in porting the basis
library.
* Port the compiler. (Assuming we're staying on X86 here)
- Add a new variant to the hostType datatype in
control/control.{sig.sml}. In your case, this would be called
MinGW.
- Compile with SML/NJ and fix all the match nonexhaustive warnings
codegen/x86-codegen/x86.fun:57.5-60.41
codegen/x86-codegen/x86-mlton-basic.fun:302.25-305.34
codegen/x86-codegen/x86-codegen.fun:225.10-228.32
codegen/x86-codegen/x86-codegen.fun:134.6-137.31
main/main.sml:455.8-472.27
main/main.sml:366.3-371.17
There's no rule for what to do here.
* Port the basis library
- Add a MinGW variant to the hostType datatype in
basis-library/misc/primitive.sml.
- Add a new case to the MLton.hostType constant using the constant
value you defined in basis-constants.h.
- Look at all the uses of hostType in the basis library code and see
if you need to do anything special. If in doubt, leave it alone
and wait to see what happens when you run the regression tests.
* Remake the compiler. I.E. run "make bootstrap" in the root
directory.
* Add support to the new compiler for the new host type. You can use
the add-cross script to do this.
* Run the regression tests with the cross-compiler. To cross-compile
all the tests, do
bin/regression -cross i386-mingw
This will create all the executables. Then, copy bin/regression and
the regression directory over to the target machine, and do
bin/regression -run-only
This should run all the tests. The only known problem is in the
real test. All the others should work.
For ease of use, I made a script that did the regression compile,
copy to target machine, and run, since it took many iterations of
this interspersed with fixing the compiler and the basis library to
get things working. If you don't want to spend the time to get some
feature working, at least put some kind of if-test and raise in the
basis library code, as I did with Posix.Process.fork on Cygwin.
* Cross-compile MLton and the tools. Again, I made a script for this
since it took many iterations. The steps are as follows. On the
source machine, do
host='i386-mingw'
make compiler tools HOST=$host
cd build/lib
rm -rf self hostmap
mv $host self
cp ../../mlton/mlton-compile .
This builds the compiler and copies it and the libraries so that
the build directory is set for the target machine. Then copy the
whole root directory over to the target machine, and on the target
do
make script world hostmap install
If all went well, you should have a working MLton and tools on the
target machine.
* Test the native compiler on the new machine by running all the
regressions normally (i.e. without the -cross flag) and by running a
couple rounds of self compiles.
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel