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.
So 1ef0c1a3e0 didn't help at all, great. Either I'm terrible enough at C++ to get the same thing wrong twice, or this is a mingw bug, in which case I'm not willing to waste time trying to figure it out.
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.
The idea is to have the following version information included:
- 1-component save version
- 2-component under the hood but the minor component shouldn't ever change again
- see currentVersionMajor in GameSave.cpp
- 1-component website API version
- again, currently 2-component because that's what the website code expects
- see apiVersion in requestmanager/Common.cpp
- 2-component display version, entirely cosmetic
- exposed as meson options display_version_major and display_version_minor
- see APP_VERSION in Config.template.h
- 1-component business logic version aka build number
- exposed as meson option build_num
- see APP_VERSION in Config.template.h
- variant id aka mod id, tightly coupled with the build number
- exposed as meson option mod_id
- see MOD_ID in Config.template.h
- display and business logic versions repeated for the upstream
- exposed as meson options upstream_version_major, upstream_version_minor, and upstream_build_num
- we'll have to update these alongside display_version_major, display_version_minor, and build_num, but mod owners can just merge our changes
- see UPSTREAM_VERSION in Config.template.h
- update channel, makes sense in the context of the variant (and yes, this would later enable mod snapshots)
- currently not exposed as a meson option but derived from meson options snapshot and mod_id
- see IDENT_RELTYPE in Config.template.h
- vcs tag aka git commit hash
- set by build.sh in ghactions workflows
- see VCS_TAG in VcsTag.tempalte.h
Rather importantly, the save and website API versions are now allowed to change independently of the display version.
These changes also allowed me to remove the ugly sed hacks in build.sh used to provision some manifest files; they are now provisioned by meson.
Also add version info for windows and android.
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 ENFORCE_HTTPS optional, but default to enabled, so unencrypted HTTP is disabled by default, and require it to be enabled for release binaries.
Also Disallow linking against non-C++ system Lua, unless configuring with -Dworkaround_noncpp_lua=true, add -Dworkaround_elusive_bzip2 and friends, and get rid of the -image_base hack for macos.
Also Factor out app constants that mods might change into Meson options and clean up format::URLEncode in the process, convert app and document icon data in arrays to actual images, actualize AppStream data for possible future packaging, add alternative command line format for opening filesystem saves and ptsave URLs, fix a memory leak in Platform::GetCwd, and add format::URLDecode.
Also restructure meson.build and the ghactions workflow a bit, and enable -ffunction-sections and -fdata-sections.
Note that starcatcher uploads have not been tested and most likely don't work.
Certain file managers need this figure out that the executable is actually executable. The problem is further complicated by meson being uncooperative and not implementing its own -Db_pie=false correctly.
I forgot to update meson_options.txt when committing 360297c. At that
point, FUTURE_SAVE_VERSION in Config.h was 96. Without that, the game
can't load saves with GOL because they save as v96 elements.
Please update your existing build sites with
meson configure -Dfuture_major=96
as this change won't affect them unless you do.
