Added caching of compiled build scripts.

[xavierzwirtz]

Caches the script file to a compiled dll when first run. Uses crc32 to hash the script, prevents using old dll when the script file has changed. Also recursively follows #load.

Takes 3312 milliseconds to interpret script without saving cache.
Takes 3326 milliseconds to interpret script and save cache.
Takes 260 milliseconds to run cached dll.

Fixes #646, and makes #645 less needed.

[xavierzwirtz]

Requires fsharp/fsharp-compiler-docs#365. It has been merged, don't know when it will be released.

[xavierzwirtz]

Implementing support for #r'd DLLs looks to be all that's missing. Only thing that's keeping my build scripts from running. Will work on fixing that.

[xavierzwirtz]

Added support for build scripts with #r and #I directives. This now runs build scripts generated by FSharp.ProjectScaffold.

[forki]

very very cool. is this ready?`whyt about the appveyor build?

[forki]

why is this commented?

[xavierzwirtz]

I was originally parsing out the included assemblies in the script files, that was the test for it. I switched to saving a list of all loaded assemblies paths and loading those on next run. Made the test not needed.

[forki]

Ok so could you please remove these?
On Jul 13, 2015 18:36, "Xavier Zwirtz" notifications@github.com wrote:

In src/test/Test.FAKECore/FSIHelperSpecs.cs
#859 (comment):

•            var newHash = FSIHelper.getScriptHash(scriptContents);
  

•            hash.ShouldNotEqual(newHash);
  

•        };
  

•    It should_get_included_assemblies =
  

•        () =>
  

•        {
  

•            var script =
  

•                "#r \"justname\"\n" +
  

•                "#r \"./relative/path\"\n" +
  

•                "#r \"C:/absolute/path\"";
  

•            var included = FSIHelper.getIncludedAssembly(script);
  

•            included.ShouldEqual(new string[] { "justname", "./relative/path", "C:/absolute/path" });
  

•        };
  

•    //It should_load_assembly =
  

I was originally parsing out the included assemblies in the script files,
that was the test for it. I switched to saving a list of all loaded
assemblies paths and loading those on next run. Made the test not needed.

—
Reply to this email directly or view it on GitHub
https://github.com/fsharp/FAKE/pull/859/files#r34482490.

[xavierzwirtz]

Removed that dead code.

[xavierzwirtz]

The appveyor build seems to be swallowing the exception that occured. Any help with that?

[forki]

if you scroll up a bit you can see the test failure

[forki]

I fixed the tests, but now I have issues with FAKE in fsreveal:

#I @"packages/FsReveal/fsreveal/"
#I @"packages/FAKE/tools/"
#I @"packages/Suave/lib/net40"

#r "FakeLib.dll"
#r "suave.dll"

#load "fsreveal.fsx"

I think we need to look in all paths.

[xavierzwirtz]

Ah, didn't realize that #load took into account #I. I can add handling for that.

[forki]

yes please send pull request. I can then update the FAKE 4.0 alpha package. I think this feature deserves it's own major version.

[xavierzwirtz]

Agreed, it has enough potential weirdness hiding in it. Are the trace calls to output the state of the cache acceptable? I could not decide if they were meaningless noise when running FAKE in production.

[forki]

I think we will put these to verbose mode before we release 4.0

[xavierzwirtz]

#859 has the fixes. Now that I have it working though, FSReveal is not going to save the cache until you stop watching changes. Felt a little odd.

[forki]

mhm. I don't think that's an issue. or is it?

[xavierzwirtz]

Not a huge issue, if you hit a key it finishes and caches it.

Thanks for the help getting this pulled in.

On July 14, 2015 1:01:48 PM Steffen Forkmann notifications@github.com wrote:

mhm. I don't think that's an issue. or is it?

---

Reply to this email directly or view it on GitHub:
#859 (comment)

[forki]

[forki]

@xavierzwirtz it seems we need a page in the docs which describes what happens here. Could you please create such a page?

[xavierzwirtz]

Created in #872.