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?

• [x] 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
• [x] Mention any related issues (put closes #XXXX in comment to auto-close issue when PR is merged)
• [x] Follow our coding conventions
• [x] Minimize the number of commits
• [x] 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.

[nickclark2016]

Just poking on this since it's still in draft status.

RE dependency module - I'd personally be in favor of getting dependencies for Premake 6.x (and potentially landing them in 5.x after the initial release). I'm picking back up work on some of the stuff that would play nicely with a dependency system in 6.x, so it feels like a potentially natural fit [[personal opinion]].

[lolrobbe2]

@tritao does this debugger also support remote debugging because i am trying to get a premake debugger extension going on vscode (mobdebug) with some inital success might be handy if i can implement both in the extension?

[tritao]

@tritao does this debugger also support remote debugging because i am trying to get a premake debugger extension going on vscode (mobdebug) with some inital success might be handy if i can implement both in the extension?

My understanding is that it's not setup as a remote debugger and is mostly usable as a local CLI debugger. I found it convenient because it does not require any setup and works out-of-the-box. Your Premake debugging extension sounds quite nice, hope you contribute that, I can help with some testing.

[lolrobbe2]

yea ill ontribute it, also was just sick of having no debugging really except for zerobrain studio

[ratzlaff]

I have had success using the "Local Lua Debugger" by Tom Blind for VSCode: https://marketplace.visualstudio.com/items?itemName=tomblind.local-lua-debugger-vscode

Add the following to the top of premake5.lua. This is where the debugger starts. You can set breakpoints anywhere after the require line:

diff --git a/premake5.lua b/premake5.lua
index 7818c1d9..ea06ae74 100644
--- a/premake5.lua
+++ b/premake5.lua
@@ -3,6 +3,10 @@
 -- Use this script to configure the project with Premake5.
 ---

+if os.getenv("LOCAL_LUA_DEBUGGER_VSCODE") == "1" then
+       require("lldebugger").start()
+end
+
 --
 -- Remember my location; I will need it to locate sub-scripts later.
 --

configure your launch.json accordingly:

        {
            "name": "Debug premake script",
            "type": "lua-local",
            "request": "launch",
            "program": {
                "command": "${workspaceFolder}/bin/release/premake5.exe"
            },
            "args": ["--scripts=${workspaceFolder}", "vs2022"],
            "cwd": "${workspaceFolder}"
        }

Set some breakpoints and enjoy:

[lolrobbe2]

I have had success using the "Local Lua Debugger" by Tom Blind for VSCode: https://marketplace.visualstudio.com/items?itemName=tomblind.local-lua-debugger-vscode

Add the following to the top of premake5.lua. This is where the debugger starts. You can set breakpoints anywhere after the require line:

diff --git a/premake5.lua b/premake5.lua
index 7818c1d9..ea06ae74 100644
--- a/premake5.lua
+++ b/premake5.lua
@@ -3,6 +3,10 @@
 -- Use this script to configure the project with Premake5.
 ---

+if os.getenv("LOCAL_LUA_DEBUGGER_VSCODE") == "1" then
+       require("lldebugger").start()
+end
+
 --
 -- Remember my location; I will need it to locate sub-scripts later.
 --

configure your launch.json accordingly:

        {
            "name": "Debug premake script",
            "type": "lua-local",
            "request": "launch",
            "program": {
                "command": "${workspaceFolder}/bin/release/premake5.exe"
            },
            "args": ["--scripts=${workspaceFolder}", "vs2022"],
            "cwd": "${workspaceFolder}"
        }

Set some breakpoints and enjoy:

this probably won't work when you have a stripped build where all the comments etc are removed from the lua files (embedded build)

[ratzlaff]

this probably won't work when you have a stripped build where all the comments etc are removed from the lua files (embedded build)

This is why the —scripts=… argument is used to launch the executable, so that both premake and VSCode read/execute the scripts from disk and not what is compiled into the executable.