[MLton] Semantics of giving a .c file to mlton?

[Ryan Newton]

Ah, thanks!  That explanation makes sense, but I would not have
guessed that gcc had such an odd convention (assumes an arbitrary
return type and continues compiling?!).

In my situation, I didn't want to have to invoke mlton twice.  (Once
to generate the header.)  That would be pretty painful (has to
typecheck the whole app twice -- several extra seconds).

However, one thing I haven't tried is making a single call to mlton,
with an -export-header flag, AND a .c file that depends on the header.
 Presumably, the ordering is such that this is safe?  This is probably
what I should be doing.

-Ryan

On Thu, Oct 23, 2008 at 12:51 PM, Matthew Fluet <fluet at tti-c.org> wrote:
> On Thu, 23 Oct 2008, Matthew Fluet wrote:
>>
>> On Thu, 23 Oct 2008, Ryan Newton wrote:
>>>
>>>  This is perhaps an undocumented bit of functionality, but I frequently
>>>  enjoy passing .c files to mlton directly, rather than compiling them
>>>  to .o files first.
>>
>> Yes, that is supported.
>
> Though, actually, I should note that the real reason for supporting passing
> .c files to mlton directly was to support debugging/resuming the codegens.
>  That is, one needs to pass appropriate -I flags to gcc to compile the .c
> and .S files produced by the C and native codegens.  Since mlton knows the
> right -I flags, it was useful to be able to invoke mlton on just a
> collection of .c files (such as might have been produced by a previous
> invocation of mlton -keep g -stop g) in order to get the right flags.
>
> A useful side-effect is that mlton will accept any .c files on the command
> line, and compile and link them into the final executable.
>
>>>  I was (probably erroneously) under the impression that I didn't need
>>>  to do -export-header, and #include the resulting file if I was passing
>>>  in .c files directly (mlton could do that for me).
>
> I don't think it is appropriate for mlton to implicitly change the meaning
> of a c file given on the command line (say, by implicitly #include-ing
> another file).
>
>