constants file

[Stephen Weeks]

> I  would  say that 1 or 2 are the best.  The advantage of 1 over 2 is that if
> some one changes, for instance, the kernel or glibc in  a  way  that  changes
> these constants then the new generated executables will know about that.  The
> disadvantage is that it makes compilation a bit longer (but probably  squat).

The important point that Matthew makes is that the constants file and
the runtime should be built at the same time.  Hence, (1) is
infeasible, since it would imply compiling the runtime for every
invocation of mlton.

> 3  is markedly worse than 1 or 2.  It means that if some one installs the RPM
> on a machine  with  a  different  glibc  or  kernel  reflected  in  different
> constants  then  the  resulting compiled programs might not work.  Note, this
> change has happened before with various glibc changes.  In  those  cases  the
> old  shared  libraries  are  kept around (so that old executables continue to
> work) but newly compiled stuff will use the new libraries, so that  would  be
> bad for us.

(2) doesn't seem to offer any advantage over (3), since we ship an
executable, mlton-compile, that was compiled with a particular runtime
(the same one it ships with).  Hence, the rpm really does depend on a
particular glibc/kernel, even if we build the runtime at rpm install.

So, it still makes the most sense to me to do (3), with different rpms
for different glibc/kernel.