constants file

[Matthew Fluet]

> 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?  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)?

> The question is, for the rpm, when should I
> create this file.  I see three possibilities.
> 
> 1. At each invocation of mlton
> 2. At rpm install time
> 3. At rpm build time
> 
> (1) is what we used to do with the old approach to constants.  (3) is
> what I'm doing now.  But (2) seems right.  Any opinions?

(2) would be o.k. if we did more building at rpm install time, but we ship
a pre-compiled libmlton.a.  I can't imagine that there are that many
constants which would change the behavior of a program (in a benign
way) under (1), (2), or (3).  In fact, I wouldn't be suprised if (1) and
(2) could lead to problems with libmlton.a using a constant in C
(hence, resolved at rpm build time) and the basis using a constant in SML
(hence, resolved at inocation or install time; in any event, possibly on a
different system than the build).  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.