Hmmm, i’ll check what compiler flags I was using, but it seems I don’t get that vc141.pdb (although I have come across that file previously).
With Handmade Hero, Casey uses the write time of the .dll to check when to reload. I found that I had to add a small delay (it was 0.5 or 1 second) to be able to copy both the dll and pdb (if I had the guess, when you call
FreeLibrary(), the debugger doesn’t release the pdb straight away, so you have to wait briefly for it to release it) although it might have been because I was compiling with CMake, so the linker was called later or, I never investigated it that far once it was working haha.
If I could pick my ideal solution it would also have:
No special flag to build for hot reload. I.e. we build exes and DLLs the same way whether we want to use hot-reload or not, it is just a runtime flag.
No copying of DLLs or PDBs. The Machinery starts up pretty fast (compared to a lot of other modern applications), but with the --hot-reload flag, we need to copy all the PDBs and DLLs which takes a significant chunk of the startup time. I’d like to get rid of that delay. (Even better would be if we didn’t need the --hot-reload flag at all…)
Yes, perfect solutions are always nice iirc live++ patches the memory directly so you can hotreload without using dlls, but using libraries is nice for keeping compile times down and I’m not sure what sort of a rabbit hole patching the memory would be.
I agree not having to use a flag for TM would be nice, it is more user friendly.
What if you had a plugin manager of sorts, and you could enable hot reloading on a per-plugin basis? On a side note, when talking about plugin loading paths, I was wondering about having projects check for plugins in their local directory, then gameplay plugins could live in one directory with their source, instead of building plugins to the TM directory, but that’s something for another thread maybe.