Duplicate file modification notifications

[crosire]

Adding this issue here for tracking: Depending on which editor is used to edit a source code file, upon saving the file is often modified multiple times so that the ReadDirectoryChangedW API will report multiple notifications for the same file. This causes blink to compile the file multiple times, which is unoptimal and slows it down. blink should try and detect when a file notification is a duplicate and ignore those.

[tankorsmash]

Potentially related: I'm running blink from VS2017 and it's opening up gvim twice when I make a change in my own project I was to hotload in VS2013. I would expect it to at least trigger VS2013 instead of gvim, but gvim is set as my default editor in windows.

I can't tell if that's why the changes aren't being applied to my exe at runtime, or if I'm doing something wrong either, but so long as I change a few things in blink::application::link, the compile completes without error: https://gist.github.com/tankorsmash/18738bec184a68f1f9aa22e3910dd540

I am running a slightly tweaked version of blink to try and run it on vs2017: https://gist.github.com/tankorsmash/94c5627af27ccf786a18017275481394, using tweaks I made just to get it to compile.

[crosire]

It shouldn't open any text editor, but invoke the compiler. There should also be a message saying "Successfully linked object file into executable image" after compilation finished, so it's not compiling anything for you. I suspect that VS2013 stores some debug data differently in the PDB/OBJ files and as such blink is not able to extract the correct compiler commandline here: https://github.com/crosire/blink/blob/171d683a3f88d85f3be7e4ffdda9069922ec2458/source/blink.cpp#L344 I only ever tested with VS2017.

[crosire]

You can try and comment out the true statement of the if in mentioned location and use the pre-defined command line instead (the false statement of that if). Provided that you run blink in a VS2013 developer command line so that the correct cl.exe is used. This has the disadvantage that preprocessor definitions and include directories are not automatically deduced, so you'll have to add them there manually (via additional /D MY_DEFINE and /I "\path\to\include\dir" arguments added to the cmdline string).

Alternativly switch your project to VS2017 if that is reasonable for you =).

[tankorsmash]

I'm running Blink through VS2017, with those modifications. I guess the WindowsTargetPlatformVersion I didn't upgrade too has the breaking changes you use for std::filesystem, but I'm not clear on any of the details there, you'd think it would work fine. I might have VS2017 working in some sort of compatible mode for VS2013.

I am trying to work through the parse_code_view_records bit, but when I place a breakpoint, there without codechanges, blink.exe either kills the exe I'm running, or stops blink.exe altogether.

I'll try to mess around with the code without debugging like you suggest and see if that helps. I tried running my project in 2017 too but it doesn't appear to be a trivial upgrade. Vs2017 does seem very nice compared to 2013 though!

edit: I think the issue with the debugging must be because of the 2013/17 difference. I can put a break in blink's main.cpp but not anywhere after it hooks into my exe. I am going to stop trying to get this working because if even VS messes this up, there has to be some deeper issues with the 2013/2017 translations that would be avoided if I just compiled my exe in 2017. Thank you for offering potential fixes! Take care!

[martty]

I too have started messing around with this; opening of the text editor happens because blink couldn't read the commandline to compile with from the debug info, and so it incorrectly assembles the "compilation" commandline as just the path to the source, which triggers the opening of the text editor.