Add interactive debugger.

[tritao]

What does this PR do?

Adds a new interactive debugger based on debugger.lua.

Premake already contains some remote debugger integration (MobDebug), however this PR introduces an integrated debugger, any call to dbg() will launch the user into an interactive GDB-like TUI shell to allow interactive debugging on the spot.

How does this PR change Premake's behavior?

New dbg() API when PREMAKE_DEBUGGER is enabled.

Anything else we should know?

There is an --interactive flag already which overlaps some of the inpect functionality available in the debugger.
Also the MobDebug --debugger flag which also provides some of the functionality, albeit in a different package.

Can we just enable this debugger by default?

If not, we could re-purpose the debugger flag and allow passing a kind --debuger=remote/mob/builtin.

Did you check all the boxes?

• Focus on a single fix or feature; remove any unrelated formatting or code changes
• Add unit tests showing fix or feature works; all tests pass
• Mention any related issues (put closes #XXXX in comment to auto-close issue when PR is merged)
• Follow our coding conventions
• Minimize the number of commits
• Align documentation to your changes

You can now support Premake on our OpenCollective. Your contributions help us spend more time responding to requests like these!

[Jarod42]

[Question] Wonder if it is not a moment to think about how to handle 3rd party in a better way
As adding another dependency would just make that job harder for the future :-/
Can't we test one other way (as submodule for example)?

[tritao]

[Question] Wonder if it is not a moment to think about how to handle 3rd party in a better way As adding another dependency would just make that job harder for the future :-/ Can't we test one other way (as submodule for example)?

Sure, I think it's a good idea, in all my projects I am doing that anyway.

I don't mind contributing my Premake dependencies module, but I've been under the impression maybe it's not going to be accepted: https://gist.github.com/tritao/a7fdf420b66c73f32f1bff286cf7f255

I think Premake should consider having something like this, it's pretty useful. Also other systems like CMake and XMake provide this kind of abstraction these days.

I have used submodules a lot in the past, and its okay, however re-using Lua and Premake seems nicer, allows defining like this:

dependency {
    name = "quickjs",
    url = "https://github.com/quickjs-ng/quickjs.git",
    path = "quickjs",
    revision = "ad834a144564955941d69a47da92dfb8c1dfa67f"
}

Then premake5 update for syncing the dependencies. Also it allows having "super" modules including the dependencies from dependencies that are using the same Premake dependencies system, and global management of dependencies, instead of needing to run Git submodule commands in different paths.