added lua support for ubuntu

[marko-kriskovic]

adds "Tools -> Lua Scripts -> Add new script" when building on linux (tested only on ubuntu)

Lua 5.1 (the language) is required for the functionality to work, but isn't provided in this PR. The user will have to install it manually. I built lua 5.1.5 from source

Tested on only one lua script (the one that I needed for my game)

Not tested if this breaks lua on windows

[rofl0r]

how's that different from the existing lua engine support? (i never used it, so i dont know how it works)

[marko-kriskovic]

@rofl0r the problem is that there is no lua engine support if you build desmume for linux. You click on "Tools" and you can just see "View Layers". I needed a way to run a Lua script

the PR adds this button and the logic behind it which only works IF you have Lua

[rofl0r]

well the codebase has lua support, and the windows version uses it (maybe also the mac os version). so if we add support for it in the linux version too, it should reuse the existing code (and put GUI elements into the same position desmume-windows users would expect them). here's a screenshot from running the latest mingw32 build under wine.

[marko-kriskovic]

sounds like a great idea. I'm happy using this code for my personal use in the meantime

[rofl0r]

I'm happy using this code for my personal use in the meantime

do i read this correctly as "take it or leave it, i don't intend to do the work for proper integration" ? if so i can close this.

[marko-kriskovic]

It's a skill issue

I'm not really familiar with the codebase. To me, it seemed like there's a windows folder for building windows and a posix folder that can be used for building linux. Mixing them didn't seem like a good idea because I don't want to break windows accidentally. I don't know where I would put the extracted code that both of them would use. I'm sure somebody else could refactor it correctly

I might look into it in a week when I have more free time

[rofl0r]

it's a similar problem to the addition of the import/export battery save (.sav) option that was added recently. b1ffe0a . basically you need to look at what the windows code does when the item in the menu is clicked (grepping for the text displayed in the menu gets you halfways there) and then do the same thing in the GTK port(s). not rocket science. if you have access to a LLM like copilot, you can even ask it to find the exact code for you.

[marko-kriskovic]

There's been a misunderstanding. I thought you wanted me to refactor both windows and posix code so it reuses the same code on building. I already did copy and paste most of it from windows. Did you want me to change the label to "New Lua Script Window"?

[rofl0r]

ok. so you use the same backend code as the windows UI already. great. so what's left to do is make everything behave exactly like in the windows version. if the menu item in windows is called X, then it must be called X too in linux. if it opens a window, we need to do the same. if the window has 2 buttons Y and Z, then the linux port must have it to. also the internal naming should be consistent. if the windows callback function when clicking on the menuitem is called "CreateLuaWindow", then it would be inconsistent to call it "addluascript" in GTK (i didnt read the windows code and dont know precisely how it's called there, just making a name up to show the point). of course the second menuitem "Close All Script Windows" needs to be added as well and behave identical to the windows version.

[marko-kriskovic]

Screencast.from.2026-06-20.13-24-00.webm

[marko-kriskovic]

@rofl0r I owe you an apology. I completely misread everything you said in your second reply because I was in a call with someone.
Can you check if the gui for windows is correct? I am currently away from my windows computer

[rofl0r]

can you provide a link to the lua script you're using?
the work looks good on first glance, but i can't currently test gtk3, as i have only gtk2 installed. maybe you could ask your llm to also write the gtk2 code based on your current version?

[marko-kriskovic]

I am using this lua script for connecting platinum kaizo to this webpage. I think it's easier to find another lua script for a game that you already have.
The lua script in question runs for both gtk3 and gtk2.
gtk3 and gtk2 have slightly different implementations and should both be tested. If you have linux installed, it should be a single command: "sudo apt install libgtk-3-dev"

[rofl0r]

thanks for adding the gtk2 code.

If you have linux installed, it should be a single command: "sudo apt install libgtk-3-dev"

i'm using my own distro https://github.com/sabotage-linux/sabotage/ and build everything from source. not every linux uses apt and binary packages. i just spent the day backporting a now required feature to wireshark so i can keep using the gtk2 version and have a lean system that doesnt waste RAM by loading a different GUI toolkit for every program.

i'll test your code in a bit and get back to you. maybe @thesourcehim wants to test the gtk3 version?

[thesourcehim]

i'll test your code in a bit and get back to you. maybe @thesourcehim wants to test the gtk3 version?

I'll get to it in a couple of weeks when I return from vacation.

[rofl0r]

@marko-kriskovic adding -rdynamic doesn't seem to be necessary for lua script support and pessimizes codegen. can you explain your use case for it? also the script you linked to requires elaborate setup, do you know of any other lua scripts for desmume that can be more easily tested?

[DarthMDev]

Im going work on lua support for macOS im assuming i could do something similar here to achieve the same thing?

[marko-kriskovic]

after playing with the vs-link lua script, I realized I had an error in the script. I fixed it, but I needed some lua symbols from .so in .dynsym. -rdynamic was an overkill. The exported symbols are the ones needed to run vs-link.so.
I will try to find some lua scripts for base games

UPDATE:
I found 2 lua scripts that are even harder to set up then this one, but not 1 that's easier yet. While trying to set one up, I realized, I'd need to put way more lua symbols in lua-exports.txt. -rdynamic would cover all lua symbols for all lua scripts, but also expose all desmume variables

[rofl0r]

after playing with the vs-link lua script, I realized I had an error in the script. I fixed it, but I needed some lua symbols from .so in .dynsym.

how so? if lua is statically linked to desmume (i.e. liblua.a is linked, not liblua.so). does ubuntu not ship static lua? IIRC the authors from PUC Rio themselves recommend linking lua statically. having the symbols exported should only be necessary if you dlopen() some external .so, but opening a lua script with the already-linked lua should not require it.

I will try to find some lua scripts for base games

thanks.

[thesourcehim]

Sorry for the delay. I can not build gtk3 frontend with this PR:
lua-engine.cpp:87:18: fatal error: lstate.h no such file or directory.
lua-devel package does not provide such file.

[rofl0r]

thanks @thesourcehim. it appears the windows port has a copy of all lua 5.1.4 headers in desmume/src/frontend/windows/lua/include/ plus a lua.7z with pre-built binaries in desmume/src/frontend/windows/lua/ (added in 84e5c98 ) whereas cocoa port has a complete unpacked lua 5.1.5 source tree in desmume/src/frontend/cocoa/lua/ . quite a mess. since the lua source is already in the repo i'd suggest we move it out of the cocoa frontend into desmume/src/ and use it from everywhere else (except windows, since the pre-compiled 5.1.4 binaries might not be 100% compatible with the headers). @rogerman do you agree ?

[rogerman]

@rofl0r, you are correct in that the Windows port ships with a .dll of the Lua library, which no other ports can take advantage of. This is the reason why the Cocoa port integrates the Lua source with it, because it can't use the Windows-style .dll. Including the Lua source also allows better platform compatibility, as well as better code flexibility if we ever want to upgrade our Lua engine in the future. I would argue that the Windows port using .dlls is what's messy -- not the inclusion of the Lua source code. I would prefer that the Windows port also used the included Lua source code rather than relying on a .dll.

If you want to move the Lua source tree from desmume/src/frontend/cocoa to desmume/src/ so that Linux can take advantage of it, then go right ahead.

[rofl0r]

@rogerman done (#981). CI is green, but please check whether your codeblocks project still works. also i didn't find how the cocoa build integrated the lua code, yet the OSX build succeeds.

@marko-kriskovic please rebase this PR on master and add -I ../../lua to CPPFLAGS so the build can find the private lua headers it needs.