constants file

[Stephen Weeks]

> > I just checked in a bunch of cross-compiler changes.  One issue that
> > has come up is that I have created a constants file that contains the
> > values of all of the target constants (e.g. ITIMER_PROF) that the
> > basis library needs.  
> 
> This would be the LookupConstants pass?  

Yes.

> Do you intend to eliminate the nullary prim's as compile-time
> lookups for arbitrary programs (as described in "Compile-time
> constants" section of the user guide)?

It won't be done with _prim any more.  The right thing is to use
either _build_const or _const.  Although right now, _build_const is
only used with a specific hardwired set of constants corresponding to
command line switches.  It's easy enough to add the ability to have -D
define the values of _build_const's.  I'm not sure what to do about
defining _host_const via include files, since those are for the
target.  I guess we could expose -build-constants and constants files
to the user.  Another possibility is to not support _host_const in
user programs being cross compiled (meaning that I would really
need to get the cross-compiled version of mlton working).

> I'd actually go with (3) -- where there are significant differences
> between the build and the install systems, that should be reflected
> with different rpms (as in the kernel and/or libc differences), or
> with different rpm building that compiles the runtime on the install
> machine.

Makes sense.  I'll stick with (2), and treat the other case as a
cross compile.