Each time, without any code changes whatsover, "Build project" (control-shift-B).
Every other build rebuilds loads of unchanged sources - wastes a lot of developer time, 29s in this case.

Please close the ide and open regedit and rename hkey_current_user\software\visual micro.

Then restart the ide add the arduino 1.6/1.8 program location to IDE Locations. Then open your project and try this again.

This will ensure you are using the visual micro default cache settings.

Thanks

First time, "Rebuild Solution":

Compiling 'blinkbuttonandweb' for 'LOLIN(WEMOS) D1 R2 & mini'
Creating BIN file elease/blinkbuttonandweb.ino.bin" using elease/blinkbuttonandweb.ino.elf"
Program size: 320,324 bytes (used 31% of a 1,044,464 byte maximum) (56.89 secs)
Minimum Memory Usage: 28568 bytes (35% of a 81920 byte maximum)
 

 

Second time, no changes, control-shift-B:

Compiling 'blinkbuttonandweb' for 'LOLIN(WEMOS) D1 R2 & mini'
Creating BIN file elease/blinkbuttonandweb.ino.bin" using elease/blinkbuttonandweb.ino.elf"
Program size: 320,324 bytes (used 31% of a 1,044,464 byte maximum) (2.51 secs)
Minimum Memory Usage: 28568 bytes (35% of a 81920 byte maximum)
 

 

Third time, no changes, control-shift-B:

Compiling 'blinkbuttonandweb' for 'LOLIN(WEMOS) D1 R2 & mini'
Creating BIN file elease/blinkbuttonandweb.ino.bin" using elease/blinkbuttonandweb.ino.elf"
Program size: 320,324 bytes (used 31% of a 1,044,464 byte maximum) (33.24 secs)
Minimum Memory Usage: 28568 bytes (35% of a 81920 byte maximum)
 

 

Fourth time, no changes..., control-shift-B …

Compiling 'blinkbuttonandweb' for 'LOLIN(WEMOS) D1 R2 & mini'
Creating BIN file elease/blinkbuttonandweb.ino.bin" using elease/blinkbuttonandweb.ino.elf"
Program size: 320,324 bytes (used 31% of a 1,044,464 byte maximum) (4.87 secs)
Minimum Memory Usage: 28568 bytes (35% of a 81920 byte maximum)
 

 
Fifth time, same procedure:

Compiling 'blinkbuttonandweb' for 'LOLIN(WEMOS) D1 R2 & mini'
Creating BIN file elease/blinkbuttonandweb.ino.bin" using elease/blinkbuttonandweb.ino.elf"
Program size: 320,324 bytes (used 31% of a 1,044,464 byte maximum) (33.66 secs)
Minimum Memory Usage: 28568 bytes (35% of a 81920 byte maximum)
 

 

Obviously not expected predictable behavior of a properly functioning make.

About the license - thanks, I'm reverting the registry accordingly, as the suggested workaround didn't have any effect.

Thanks, so to be clear you are saying the problem happens with you custom tool chain in documents\arduino\hardware (sketchbook\hardware) but does not happen with packages installed using board manager or built in arduino ide (avr)?

Ah okay, so to be clear. If you have a package installed into board manager and another copy of the same (or similar) core from the package installed into sketchbook\hardware then we see the problem?

edit: I think I have anough to experiment. This seems to be an issue with split or partl duplicate toolchain/cores maybe.

I hope you'll be able to figure this out without external help from the FOSS project - it would be so much nicer not having to spend 30s on each compile in vain. Thanks!!!!!!!!

It looks like Visual Micro is basically doing the right thing. The confusion appears to be caused by your prebuild event hooks where you geneterate a new version number .h file.

The version number changes during each build and you have linked the version.h into the libraries (maybe via the core). 

The libraries use more than simple date time of each .cpp to determine when rebuild it need. It uses the .d depency file generated by previous build to discover all depencies of each source code file, so that it can compare the dates and times of dependants with the current source file (cpp). 

Therefore because your version number changes for each build then we would expect the libraries and project code to be rebuilt each time the build happens.

In the next release of Visual Micro there is a new build event hook that fires only when the date time or a core file has changed called "core.prebuild_if_changed". If you move your core.prebuild event hook then you get a new version.h only when you have changed a core source core.

The fact that you see alternate build is probably due to when the hook is run and the fact that you create it in the core temp build folder itself. Maybe it should have rebuilt every single time to cause less confusion.

Does this make sense? 

These are the hooks in your custom core.

recipe.hooks.sketch.prebuild.pattern="{runtime.tools.python.path}/python" "{runtime.tools.signing}" --mode header --publickey "{build.source.path}/public.key" --out "{build.path}/core/Updater_Signing.h"
>>> recipe.hooks.core.prebuild.pattern="{runtime.tools.python.path}/python" "{runtime.tools.makecorever}" --build_path "{build.path}" --platform_path "{runtime.platform.path}" --version "unix-{version}" 

So, it's all about this one, right:

_version.h ?

It seems in esp8266/tools/makecorever.py, in Git builds - as opposed to releases where core_version.h get placed once and for all into cores/esp8266 - the python script generates the same file contents for core_version.h over and over, but obviously updates the file time stamp. And that's consistent with what you found.

So all it might take is some hacking of the python script... yes, confirmed, if I comment out the writing of core_version.h, the build time without changes becomes a consistent 4.5s.

Thanks for looking into this, I guess I'll pick up from here.