Normally you dont have to clean and rebuild, building just works fine. So your tutorial is great and helpful to people to not accidently rebuild everything. This here however is a different case.
The engine targets are part of the game’s solution exactly as they would be in the solution created for the github sources, Rama. RPotters command line does exclude the engine targets though. But a rebuild on the game project in this solution triggered again a rebuild of 1265 targets instead of a few. ZFS alike for Windows or a some fast computers here would be soooo helpful.
@RPotter + all
As far as I can tell the shell extension project generation adds the -engine switch its info in Engine\Source\Programs\UnrealVersionSelector\Private\UnrealVersionSelector.cpp around line 162 (on 4.5 preview).
But that ends to be just cosmetic in nature to edit the files with Visual Studio.
Building and rebuilding looks like to be under sole control of UBT, and as far as I can see it iterates over the combination of engine and game sources to create lists of targets to be cleaned and build. It accepts parameters to control which modules are due to get build and rebuild, but I guess thats just what is called when you issue Build or Rebuild from the Visual Studio interface.
So far if I have it right UBT only seperates out the engines targets of it when it builds for a Rocket target; so an engine built by Epic, delivered through the launcher. (Look f.e. at UEBuildTarget.cs in UBTs sources)
Last time I tried to get UBT to treat an github build as like a Rocket build for a game project was with 4.2 or 4.3 and that didn’t work. I dont know if one can build the github source to be like the Rocket version.
If you figure out some more, some better, RPotter, that would be great.
Or we convince the UBT programmers at Epic to solve it for us
If the issue that lead to the need to rebuild still stands, did cleaning by hand worked out?