Elements: Improved Dependency Caching for References

(marc hoffman) #1

Happy new year, everybody!

The first new Elements build of the year is out, with a bunch of new improvements. The most significant, I think is the new Improved Dependency Caching for References in EBuild, so I wrote a Blog post about it:

Other new features include the ability to double-click error messages in the textual build log to navigate to the error locations, and a whole bunch of debugging improvements in Fire/Water, including support to change the “Next Statement” when stepping thru code, and to add Conditions to breakpoints.

One down, 51 more to builds to go, for 2019 — it’s going to be a very exciting year!

(marc hoffman) #2

(JohnMoshakis) #3

Do you know what kind of speed improvement you see when building Fire ?

I like being able to navigate from the build log.

Could you give a more detailed explanation of debugging improvements ?

(Carlo Kok) #4
  • Support for Conditional Breakpoints
  • Support for “Set Next Statement” when debugging (CoreCLR, CLR and Island)
  • Lots of improvements for arm stepping

There were also a lot of minor tweaks of the debugger that should give better results.

(All of this for the Island debugger (water and vs) and .NET debugger in Water)

I can’t talk about what marc sees in Fire but in the compiler I see that if I make a change in the implementation of the Compiler dll, it skips compiling:

  • .Echoes,
  • .Code.Test,
  • .Cooper,
  • .CoreDebugEngine,
  • .Island,
  • .Oxidizer,
  • .Toffee
  • .Tools.

Basically, it skips all of them even though they all depend on the Compiler dll, unless it’s an interface change of course.

(marc hoffman) #5

Same here, basically. there’s no concrete “speed improvement” in the sense that the compile is faster, it’s more that redundant steps are skipped. Fire takes about 3-4 minutes to build, all in all, if I build all projects. As I mentioned in the blog post, before this change, I would manually manage what projects were enabled to avoid unnecessary rebuilds of projects that weren’t affected, but that was error prone of course (eg if I did make a public change and didn’t let the right ons rebuild, ting would then fail to link or run, etc). Also, the main project always had to build, since I needed it to link.

Now,only the one project I make a change it builds, the rest skip the compile phase, and the main app still links.

Note that my build times are “extra slow” because 'm working on a 12" MacBook, which only has an m7 chip :wink:

(JohnMoshakis) #6

I’ve been working on a solution with some ios projects and there is noticeable speed difference between me changing something in one of the projects and deploying to the simulator.
I have some other solutions with more projects that Im looking forward to trying.

I guess your thinking of buying a new machine ? What are you going to replace it with ? I have a 2012 mac mini, which is now way too slow with xcode, I was thinking of getting a new one but the prices seem to be sort of comparable to a macbook or air and I wasnt sure what to get.

(Patrick Lanz) #7

Nice addition to the chain tool, but it seems that sometimes it compiles a project when not needed.
Unfortunately I can only tell by looking at the time in the output window of Visual Studio. Perhaps it should be possible to add something in the output window to indicate that a project is not compiled: “compile step skipped” for example.

(marc hoffman) #8

Can you try running with the --debug --debug-caching command line switch, this gives more detail as to which file invalidated the cache.

that’ll be there, off you turn the logging level up to Verbose or higher.

(marc hoffman) #9


No, I love the form factor, and feel most comfortable with it.

I have a (faster) 2016 MacBook Pro, but it feels too chunky for me (even though I reality its pretty slick and slim. The 12" has spoilt me). And my Mac Pro recently gave up the ghost, but I don’t miss it because I haven;'t been using that for anything real, since we moved.

The 12" MacBook is just perfect for all my needs; I’ll upgrade it when there’s a newer and faster version, but I’m very happy with it in every regard.

yeah, the Mini’s of that generation did not the well. :frowning:

I’d get a 2018 MacBook Pro 13" with TouchBar, if you want a reasonable work machine.

(Patrick Lanz) #11

Mark, I have a case when changing a single letter in an XML comment makes another project in the same solution (but not all dependent projects) to compile!

Can you reproduce or do you want a test case?

(marc hoffman) #12

I assume the one that recognizes,piles directly uses the project with the chawed XML, and the ones that don’t only use it indirectly (eg via the one that recompiles wrongly?)

If so, I assume the problem is merely that XmlDoc changes are treated as a public change, when they should not be; I’ll check with Carlo and log.

(Carlo Kok) #13

XML isn’t seen as a part of the public signature at all no. Any chance of a simple tsetcase that shows this? Tried it in VS but it seems to act fine here.

(Patrick Lanz) #14

I see it in the VIS application, not a small testcase…

(marc hoffman) #15

Can you build it with --debug --debug-caching from the CommandLine, after you touch the xmldic, and send me the log file here?

(Patrick Lanz) #16

“Detailled” or “Diagnostic” in the Visual Studio settings?

(marc hoffman) #17

No. you need --debug-caching, which you can only get on the Command Line, sorry. --debug will imply Diagnostic logging.

(Patrick Lanz) #18

And how do you start a command line build?

(marc hoffman) #19

Just run

ebuild c:/path/to/your.sln --debug --debug-caching --configuration:Debug

(assuming that in VS you’re using the Debug configuration)

(Patrick Lanz) #20

I have the following log (it’s an ASP.NET web site):

RemObjects EBuild. An open source build engine for Elements and beyond.
Copyright RemObjects Software 2016-2019. All Rights Reserved. Created by marc hoffman.
Version (develop) built on bajor, 20190104-155057. Commit 6c09e87.

Exception: Object reference not set to an instance of an object.
|    at RemObjects.EBuild.EBuildSolution.LoadFromString(String aString, Boolean aLoadProjects)
|    at RemObjects.EBuild.CommandLine.Load(String aFileName)
|    at RemObjects.EBuild.CommandLine.RunWithParameters____HostMode(SimpleCommandLineParser aParameters, Boolean aHostMode)

(marc hoffman) #21

Hmm, thats the same .sln that builds fine from VS? I’ll need to see a testcase, it seems it cannot even parse the .sln file…