[MLton] MacOS linking broken?

[Matthew Fluet]

>> It appears that linking MLton programs with Mac OS X frameworks is broken 
>> in the latest SVN revision (it was working in r4796).
...
>> NEW:
>>      gcc -o triangle /tmp/fileZ7FdMM.o /tmp/fileL3aAgK.o \
>>          /Users/jhr/Work/hacking/sml3d/glut/glut-glue.o \
>>          -L/Users/jhr/Work/mlton/mlton/build/lib/self -lmlton -L/sw/lib \
>>          -lgdtoa -lm -lgmp \
>>          -framework GLUT -framework OpenGL -framework Foundation
>
> I note that if you compile with -keep o and then replicate the gcc linking 
> line at your shell, then the linking succeeds; so, it looks like the call to 
> gcc is being messed up somehow, probably in the way arguments are being 
> passed.  I'll investigate.

There was a commit on the x86_64 branch (r4610) that attempted to 
robustify the -{,target}-{as,cc,link}-opt command line options in the face 
of arguments with spaces.  Before this commit, the 
argument to -target-link-opt was tokenized (splitting on Char.isSpace) and 
the the resulting list was incorporated into the list of arguments to gcc 
for the Posix.Process.execp invocation.  After this commit, the argument 
to -target-link-opt is not tokenized and the entire string is incorporated 
into the list of arguments to gcc as a single argument.  So, one can 
replicate mlton's behavior at the shell as follows:

gcc -o triangle /tmp/fileZ7FdMM.o /tmp/fileL3aAgK.o \
            /Users/jhr/Work/hacking/sml3d/glut/glut-glue.o \
            -L/Users/jhr/Work/mlton/mlton/build/lib/self -lmlton -L/sw/lib \
            -lgdtoa -lm -lgmp \
            '-framework GLUT -framework OpenGL -framework Foundation'

What I find odd is that gcc/ld don't complain about the weird argument; by 
default it should interpret it as an object file to be included in the 
link, but clearly there is no file with that name around.

In any case, the pre-r4610 behavior is available through the 
-{,target}-{as,cc,link}-opts (note the final "s") command line option.

However, I think it is wrong to break the behavior of the old options, 
especially since the vast majority of users will not need to handle spaces 
in path names.  I propose to reverse the behavior, so that the -opt option 
does Char.isSpace tokenization, while -opts (or, possibly, a better named 
option) doen't perform tokenization.

So, the short-term solution to John's problem is to use 
'-target-link-opts' rather than '-target-link-opt'.