[MLton] Cygwin->Mingw32: patch + future
Stephen Weeks
MLton@mlton.org
Fri, 19 Nov 2004 07:24:35 -0800
> I built a cygwin->mingw32 mlton cross-compiler last night, and it
> works!
This is good to hear. It would be nice to see the MLton MinGW port
get finished.
> There were only two issues:
> 1. With gcc-3.4, the '-b <arch>' must be the first argument.
> 2. When using cygwin to compile native windows applications via their
> included mingw compiler, the option to use is '-mno-cygwin' instead.
> (I don't know why they did this, but there you have it)
OK. I've included your patch.
One thing I did change was the condition for using -mno-cygwin. It is
now
Cygwin = MLton.Platform.OS.host
andalso String.hasSubstring (s, {substring = "mingw"})
Testing for "mingw" instead of "i686-pc-mingw" is a bit more general
and hopefully still OK.
> In general, I think most of the CC-controlling options should be
> moved into a config file somewhere.
As Matthew pointed out, most of them are outside the binary. And as
you pointed out, not all of them are. Unfortunately, I don't see an
easy way to move the remaining ones out.
> Some people might want to use 'icc' for example, or under windows
> one of those other non-free compilers.
Once these start getting used, maybe there will be more of a push to
improve the situation.
> I propose to add in MLTON_PROCESS (or maybe MLTON_CHILD?):
I like your proposal. Adding your stuff to MLTON_PROCESS seems fine.
I have some minor points/questions.
* What is the NULL iosource for?
* What is RedirectionFailure for?
* It seems like you missed the ability to pass the three iosources
(stdin, stdout, stderr) to create.
* I propose to strengthen the use of phantom types. Right now, all
they do is prevent is turning the same file descriptor into both a
binary and a text stream when using {bin,text}Std{err,in,out}Of. We
can use them to express whether or not the stream can be extracted.
Once we do that, we can also drop the option return type.
* I wonder if it makes sense to change the semantics from how the
Unix module behaves so that, e.g., two calls to textStdinOf return the
same stream instead of creating a new one (which has no reasonable
behavior).
* I don't think the "Of" suffix does anything. I propose to drop it.
* For future reference, here's the Microsoft docs that I looked at for
CreateProcess.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/startupinfo_str.asp
Here's a MLtonization of your signature, with my proposed changes.
----------------------------------------------------------------------
signature MLTON_PROCESS =
sig
(* Phantom types to keep track of whether a process's IO source is a pipe
* and hence whether we can extract a corresponding stream.
* Also keep track of the stream's type (bin or text)
*)
type bin
type text
type 'a isPipe
type 'a isNotPipe
structure Source:
sig
type 'a t
val file: string -> 'a isNotPipe t
val inherit: 'a isNotPipe t
val lie: 'a isNotPipe t -> 'a isPipe t
val null: 'a isNotPipe t
val pipe: 'a isPipe t
end
type ('stdin, 'stdout, 'stderr) t
val binStderr: ('a, 'b, bin isPipe) t -> BinIO.outstream
val binStdin: (bin isPipe, 'b, 'c) t -> BinIO.instream
val binStdout: ('a, bin isPipe, 'c) t -> BinIO.outstream
val create:
{args: string list,
command: string,
(* env = NONE means use the parent environment. *)
env: string list option,
searchPath: bool,
stderr: 'stderr Source.t,
stdin: 'stdin Source.t,
stdout: 'stdout Source.t}
-> ('stdin, 'stdout, 'stderr) t
val kill: ('a, 'b, 'c) t -> unit
val reap: ('a, 'b, 'c) t -> OS.Process.status
val textStderr: ('a, 'b, text isPipe) t -> TextIO.outstream
val textStdin: (text isPipe, 'b, 'c) t -> TextIO.instream
val textStdout: ('a, text isPipe, 'c) t -> TextIO.outstream
end
----------------------------------------------------------------------
> This interface could then be used to implement Unix.* and the
> corresponding Windows.* methods. Also, by using the
> mlton_create_process syscall, there would no longer be a need for
> the spawn syscall. I would remove it in favour of the more powerful
> syscall and change the spawn code to use it instead.
Sounds good.
> The MLTON_PROCESS/CHILD implementation would be conditioned on Platform.OS
> like spawn is now. (ie: use mlton_create_process or fork/exec)
Also good.
> Is anyone working on providing Windows : WINDOWS? (should i?)
I don't know of anyone who is. We'd be happy to have you working on
it.
> Has the "path handling to get CM files to build properly" been fixed?
No.