I have had a lot of research on this topic just before setting up my engine because I wanted the perfect repo structure, the perfect code clearness and perfect speed. Now I now that there isnt something perfect just that what you are willing to work with or not work with.
One of the results I'm very happy with is to compile anything from the framework/engine code into static linked libraries that has the advantage that you could easiely modulate your code. I have set up everything to be as most standalone as possible but also capable to use the full power of any module that exists. When a module uses functions from another one it is not a problem to make a static linked library from them because linker will assemble anything into the executable correctly (Tested in MSVC 2010/2015, GCC LLVM)
To setup a new project a need just a build file where I specify whatever module I want to use and run the tool from the engine directory that setups a VS project for it even when I have also seen a lot of copy/paste project setup or starting a project from a tutorial of the library we then used, I think this is something more clean to get it.
In my system I have a macro that setups the typical main call for targeted platforms requireing an init, main and cleanup function to be called. In the engine I'm currently working on there is a file Engine that contains static functions in a namespace that setup memory management and clears it after anything is finished running. These two functions are put into the macro so that
int main(Array<const char*> const& args)
{
return Engine::Run();
}
__app_entry(Engine::Initialize, main, Engine::Cleanup)
is anything that the executable needs to call to get the game up working. The Run function then takes control over the OS specific message loop, queries main thread of the job system and registeres a small event callback to shutdown everything properly; thats it! And in my opinion it is enougth because anything else like loading config settings into the engine or register systems at the task manager has to be done before Run.
The rest is scheduled by the task manager when the system is setup and running regardless of if it is an engine system like rendering or something gameplay related like character controller.
I also decided a completely data driven approach like old TES Oblivion did where replacing the main .bsa file meant to have a completely new game (what some modders did) but the decision against it was simply performance related where having anything in scripts may be a critical impact.
I'm happy with it because it is as generic as possible and also as near to the engine code as needed. Maybe you might think that there is something that better fits your needs