Assuming that I understand the situation correctly, does the following
action sound suitable?
I can add an additional parameter to Dyre named 'recompileCheck' which
will determine whether the program should attempt to recompile custom
configurations or whether it should simply proceed directly to the
main entry point with the provided configuration. The advantage of
doing this, as opposed to returning multiple entry points, is that it
allows programs which have no need for that capability to simply
ignore it, and always use the recompile support.
Basically, the code in Boot.hs would then look like this:
<code>
yiParams = Dyre.defaultParams
{ programName = "yi", ... }
yi = Dyre.wrapMain $ yiParams { recompileCheck = False }
defaultYi = Dyre.wrapMain yiParams
</code>
The 'defaultYi' entry point would be used by the main executable, and
would always check if it needed to compile and/or run a custom
executable, but the 'yi' entry point, which would be used in custom
configurations, would dispense entirely with those checks, and simply
proceed to the main program function after doing its little bit of
startup housekeeping.
If no one raises any objections to this action, I should have v0.7
uploaded to HackageDB within an hour or two.
- Will Donnelly
On Aug 7, 6:37 pm, Will Donnelly <will.donne...@gmail.com> wrote:
> I'm trying to understand exactly what's going on here. As far as I can
> tell, the '-fhacking' flag is used to indicate that a custom
> configuration is to be used as the application's default entry point
> for hacking purposes, correct? And then, the patch seems to indicate
> that the desire is also to disable recompilation functionality
> entirely (which makes perfect sense, given that you don't want the
> config in "~/.yi/yi,hs" to override the one in HackerMain.hs).
>
> If my understanding of the above is correct, then I think the issue is
> that HConf would pass control directly through (without recompiling)
> when called with a custom configuration, and Dyre attempts to simplify
> the control flow by using a single entry point, which will always
> recompile if applicable. I will try to see if I can find a good
> solution to this, but in the meantime, I have a question:
>
> Shouldn't GHC consider a change in an applicable flag to be equivalent
> to a change in the source code? It has the same effect on the code
> which GHC ultimately sees, so it seems strange to treat one
> differently than the other. I understand that the flags are actually
> handled by the C preprocessor, and not by GHC, and that it could be
> prohibitively difficult to preprocess every file before checking for
> changes, but it seems that the patch, as posted, theoretically
> *should* work without needing the "touch src/Yi/Boot.hs" call.
>
> Please let me know if I misunderstood any part of the discussion
> - Will Donnelly
>
> On Aug 7, 3:44 pm, Jean-Philippe Bernardy
>
>
>
> <jeanphilippe.berna...@gmail.com> wrote:
> > On Fri, Aug 7, 2009 at 10:35 PM, Jeff Wheeler<jeffwhee...@gmail.com> wrote:
>
> > > The problem with this solution is that Yi.Boot needs to be recompiled
> > > before the changes are recognized, so I have to `touch src/Yi/Boot.hs'
> > > to enable -fhacking. This won't do …
>
> > That's a tad annoying indeed.
>
> > >> I don't see how to do this the HConf way.
>
> > Would it be acceptable to modify Dyre so that it produces two entry
> > points (one for the static executable,
> > one for the configuration)?
>
> > Cheers,
> > JP.
--~--~---------~--~----~------------~-------~--~----~
Yi development mailing list
yi-devel@googlegroups.com
http://groups.google.com/group/yi-devel
-~----------~----~----~----~------~----~------~--~---
