On Sun, Jun 28, 2009 at 21:14, Thomas Schilling<nomin...
> Scion can do everything that "ghc --make" can. Generating binaries just
> requires setting a different hscTarget and ghcLink options (see
> Scion.Session.initialScionDynFlags and GHC.DynFlags). The problem is that
> if we need to change static flags (e.g., enable profiling or threaded
> builds) then we need to start a new process.
But these kinds of flags require a full recompile anyway, right? In
that case, the overhead of restarting the Scion server is negligible.
> In GHC 6.11/12 I added an optional callback to the --make facility. The
> callback is called after compiling each module with the messages generated
> from it.
That would be good. We could keep the client up to date about
compilation status. It would sort of break the request/response model
that we currently have, but that is not a problem.
>>> So maybe you could consider this as an option. It might also help with
>>> the progress reporting and threading issues you mention below.
I reimplemented the output parser in Java for the time being. It works.
> A simple solution would be to just print the GHC output to a console. (his
> can by calling the 'ghc' command line utility and just showing its output in
> some window. Alternatively, you can set the 'log_action' callback from
> within the GHC API.
Yes, GHC output is *also* printed to a console in the current
EclipseFP version. But then we don't have error highlighting and such,
which is why it needs to be parsed. And consider automatic background
recompiling; it's no good to distract the user with a scrolling
console every time some file is saved.
> Using two concurrent Scion-servers shouldn't be such a big deal. The
> question is whether they should be managed transparently by Scion or by the
> front-end. I'm leaning towards the former.
If we were to have two separate instances, would they be able to use
each other's compiled results? In other words, will the "load" command
load the compiled result from disk, if it is present and up-to-date?
If this is not the case, then two instances again seems like we're
compiling everything twice, which is exactly what I would like to
> I don't think that function is meant for that purpose. The
> compile/typecheck/loadModule do generate output if the DynFlags are set
> correctly. I think that's what you should use.
That's great! Scion would just need one extra command to change the
hscTarget and maybe ghcLink. Or, better IMHO, add a parameter to the
"load" command to indicate whether code generation should be done.
Makes the whole thing a bit less stateful and easier to manage for the
> If Scion is too unreliable then it should be fixed. Thomas, do you have any
> concrete concerns?
Not regarding the reliability of Scion, no :) But I'm slightly worried
that pinning ourselves down on Scion too much will also create a
dependency on GHC. I think we can assume that the user has GHC
installed, and thus can install Scion too. However, I think we should
*not* assume that everyone always wants to compile their code through
GHC. E.g. even when developing on GHC, people may want to test their
code using a different compiler, to check that it works for everyone.
> The somewhat unsatisfactory feature is it's build support. This part is
> pretty much single-threaded, because it relies on 'ghc --make' and has very
> simple preprocessing facilities.
> Another problem is that Cabal doesn't play well as a library, yet, because
> any error tries to exit the program.
> I CC'd Duncan, Cabal's main developer, because he probably has some thoughts
> on that matter.
Well, as Duncan replied, this will be fixed with Cabal 1.8 / GHC 6.12,
which is great! Combined with nominolo's new "ghc --make" hook, we
could call Distribution.Simple.Build.build and keep the client up to
date as well.
Distribution.Simple.Configure.configure would also need to be run at
some point, but there we can probably get away with piping the output
to a console. By parsing and checking the Cabal file first
Distribution.PackageDescription.Check) we could catch many errors in
advance and highlight them in the IDE.
So we now have several alternatives to building stuff from the IDE:
1. invoke ghc --make through a command line, parse output
2. invoke ghc --make through Scion
3. invoke cabal configure && cabal build through a command line, parse
output (does not necessarily use GHC)
4. invoke cabal configure && cabal build through Scion (does this
necessarily use GHC...?)
5. invoke some other compiler through the command line, parse output
1 or 2 are good options in case no Cabal file is available. This would
be the case for simple programs, for example in education. In these
cases, the IDE needs to figure out (or be told) what the main file(s)
is/are, and the main function therein (of course, this should default
to Main.main). Currently, EclipseFP does not do this, but simply
invokes "ghc --make" on every file. GHC flags should be configurable
from the IDE (they already are).
3 or 4 would be good for package developers. The options to be passed
to "cabal configure" need to be configurable from the IDE, and there
should be a way to specify different sets of options (build
5 is just something to be designed for, because I will probably not
implement support for any other compilers.
So there can be different "builders" for a project (GHC Builder, Cabal
Builder), and every builder can have multiple "configurations" (flag
settings, etc.). This is something that Eclipse supports nicely.