This causes these dependencies to be rebuilt if the script chanages, which is heaps better than having to remember to clean the build directory every time.
So they get copied into the build site even if you invoke only the powder build target, rather than all build targets by not specifying one. Case in point:
meson compile
vs
meson compile powder
wherein the latter will build powder.exe but will not copy the dlls into the build site, which are required by powder.exe.
The assumption was introduced by 7e674a887d69, where find_program('python') was used instead of Meson's built-in python discovery services. This turned out to be a bad idea because of course there are systems in 2024 where python is not python 3.
May fix pipeline failures on ghactions where makeico or toarray just exit with a non-zero status for no reason.
Also makes it easier (possible, rather) to build TPT using a cross-compiling msvc toolchain on windows; you can't have two different msvc toolchains in PATH on windows because of course you can't.
toarray had been python before, maybe I converted it to cpp to avoid pulling in python as a dependency, I'm not sure. With android vanilla development (hopefully) gaining traction soon, we'll be relying anyway on helper scripts I've written in python, so python will be a dependency sooner or later. Meson implicitly makes python a dependency, but there could be Meson implementations out there that don't rely on python, who knows.
Which optionally enables loading Lua shared modules from within even static TPT. Not that anyone actually needs this.
This currently can't work on Windows because DLLs there import symbols by [module name, symbol name] rather than just symbol name. One could in theory export Lua symbols from TPT (I don't know the exact MSVC hack this would require, .def files?) and place a lua51.dll next to the executable that just re-exports them, see https://learn.microsoft.com/en-us/cpp/build/reference/exports?view=msvc-170 , but I've yet to try this.
I was hoping SDL2 would get this functionality eventually, but nope, proper clipboard support is staged for SDL3, which we're not going to see much of for at least a few more months. This will have to do for 98.0. The feature can be disabled at runtime from powder.pref.
Implementation status:
- windows (via winapi): has the most friendly api so of course the implementation is flawless and uses every available optimization >_>
- macos (via cocoa): I'm bad at cocoa so this is only as good as absolutely necessary; TODO: on-demand rendering
- x11 (via xclip): I am NOT implementing icccm2; TODO: remove reliance on external tools
- wayland (via wl-clipboard): oh god wayland oh why, you're almost as bad as x11; TODO: remove reliance on external tools
- android: TODO; is there even a point?
- emscripten: TODO; the tricky bit is that in a browser we can only get clipboard data when the user is giving it to us, so this will require some JS hackery that I'm not mentally prepared for right now; also I think the supported content types are very limited and you can't just define your own
x11 and wayland support are handled by a common backend which delegates clipboard management to xclip-like external programs, such as xclip itself or wl-clipboard, and can load custom command line templates from powder.pref for use with other such programs.
I have absolutely no idea. The error in question is the following:
wasm-ld: error: /home/lbphacker/.emscripten_cache/sysroot/lib/wasm32-emscripten/lto/libhtml5.a(callback.o): attempt to add bitcode file after LTO (_emscripten_run_callback_on_thread)
I have no idea where we use _emscripten_run_callback_on_thread, and I have no idea why LTO would think it's not required when it's obviously required. This commit fixes it by holding the linker's hand even more than it already had.
This allows multiple instances of the game to be loaded in a single page.
Also stop emitting htmls as a build artifact and require presence of #PowderSessionInfo.
Namely: no, yes, and yes and ask at startup.
The install_check option is thus replaced by the can_install option. -Dinstall_check=true maps to -Dcan_install=yes_check, while -Dinstall_check=false maps to -Dcan_install=yes. -Dcan_install=no is new and is recommended for downstream packaging, where -Dinstall_check=false was historically used.
Also improve error messages about bad configuration here and there and scatter configuration code in subdirectories, where they can be closer to their areas of effect.
Also make it easier to test tpt-libs builds locally by making it possible to point build.sh at a local tpt-libs repo and move installation of build dependencies to build.sh.
Also make ENFORCE_HTTPS optional, but default to enabled, so unencrypted HTTP is disabled by default, and require it to be enabled for release binaries.
Also write PNGs with libpng, and BMPs with SDL, and have the renderer only generate a large PNG thumbnail, and disable HTTP/2 multiplexing for now so we don't get banned when loading avatars.
simon pls reply to the stupid emails already.
Also make it and render get built as dynamic executables on ghactions, and disable dynamic+LTO, as it seems to be buggy in certain cases and isn't an important case.
