caching for runghc (runhaskell)

[jsnx]

I'd like runghc to compile and cache scripts, so they will run fast after the first shot. This could be available via a command line option, special name (runhaskello), or be governed by a config file -- I'm open to suggestions here.

I still haven't quite worked out how to do this -- I'll have more ideas about the layout of the cache in a few days.

I'm making a feature request of it not because I want someone else to do it, but rather because I'd like it to be accepted once I finish it and I wouldn't want to invest all the time and trouble in reworking runghc if it's just going to be rejected.

[duncan]

How the -fobject-code flag. In fact it may work already, I don't know. In ghci it means to compile all the .hs files to .o and to load them instead. I see no reason it could not do the same for runghc.

No need for a complex cache, just use the ordinary --make behaviour along with the -hidir and related flags for changing where the generated files go and are looked for.

[jsnx]

Replying to duncan:

How the -fobject-code flag. In fact it may work already, I don't know. In ghci it means to compile all the .hs files to .o and to load them instead. I see no reason it could not do the same for runghc. No need for a complex cache, just use the ordinary --make behaviour along with the -hidir and related flags for changing where the generated files go and are looked for.

Well, sure, I can do it with a shell script instead. What I'm offering is integrated, system-wide caching for scripts with #!/usr/bin/env runhaskell in their first line.

If it's not seen to be of value, there's no point in my writing -- as you suggest, I can just make a shell script for it if it's going to be a private thing.

[jsnx]

Replying to jsnx:

Replying to duncan:

...

...

I realize now that I may have misinterpreted your message. I was actually planning to use --make to do the caching, but I wanted to be sure that the cache was shared across users and respected differences in GHC versions. This might lead to a cache like /tmp/runghc/<runghc version here>/<actual cache here>. It's also worth examining the security dangers of a system wide cache. They may be severe -- evil object files could be substituted for correct ones if all users have write access to the cache. So maybe we need to spawn a separate process that calls a setuid program to do the compilation?

[igloo]

Security is definitely a concern here. And you need to make sure that you have exactly the same source code, inlinings from imports, appropriate commandline flags, etc.

[jsnx]

Replying to igloo:

Security is definitely a concern here. And you need to make sure that you have exactly the same source code, inlinings from imports, appropriate commandline flags, etc.

How much of this will --make actually handle?