Like 5103db82887f, this addresses the upload issues experienced on windows, but this time with the official fix from libcurl developers; see the relevant tpt-libs commit.
This fixes upload issues (mainly on windows, though I've found no reason why it wouldn't manifest elsewhere also) and enables querying display refresh rate when using xorg.
C++11 standardizes the "nullptr" keyword, which replaces the
implementation-defined macro null pointer "NULL" or a hardcoded 0.
---------
Co-authored-by: Tamás Bálint Misius <lbphacker@gmail.com>
Meson generators seem to be a dying feature, evidenced by the fact that they have been in a state of isolation from the rest of the language for several years at this point:
- very few things accept generator outputs as inputs, not even generators themselves do
- unlike configured files, their outputs aren't guaranteed to be always synthesized, and yet they can't be passed as dependencies to other targets
- they accept strictly one input and can't depend on other files
This makes them really hard to work with in a context that would require either a project resource or a target. Custom targets don't have any of these shortcomings, so this commit migrates embedded files over to those. A real shame, considering that generators can be used anywhere and are generally less messy than custom targets.
This considerably speeds up linking of release binaries with msvc when testing locally, when LTO is of no concern.
Also properly override b_lto and b_vscrt in all cases for all targets, never leaving them to take default values.
This leaves one non-C++ TU in the entire codebase: Cocoa.mm is Objective C++ and is only compiled on MacOS, where it's used for clipboard integration. This too will go away when we move to SDL3, which has a proper clipboard API.
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.
