Update LuaJIT to mainline 2.1 via Meson WrapDB

[Architector4]

Turns out, Meson has a whole system for managing non-Meson dependencies with a bunch of prebuilt patches they maintain. One of them is LuaJIT, and it's newer than the rather ancient Meson-compatible LuaJIT fork by franko that lingered in this repo.

The game builds and runs fine, (even with --force-fallback-for=luajit) and undefined behavior sanitizer no longer spews lots of errors about misaligned memory reads and stores. It might even have other bugfixes or performance improvements too, I don't know lmao

One nice thing about this Wrap thing is that the new source folder, LuaJit-04dca7911ea255f37be799c18d74c305b921c1a6, can be deleted entirely. On build, if needed, Meson fetches it automatically from the luajit.wrap file (via external/sources/packagecache dir, which I .gitignore'd).

I kept the folder though because, as I understand, it's the style of this repo to have all the dependencies self-contained for offline building or whatever.

This commit also adds the .wraplock file to .gitignore. Meson adds this file there on every build ever since version 1.9.0 (released in this August), and it's getting annoying removing it or making sure it's not staged every time lol

...Yeah, this is a big change. Would not be surprised at all if @HeliumAnt would have things to object to; for all I know this just messes everything up and is done all wrong, so do yell at me as needed :D

[Architector4]

goddamnit what lol

[Architector4]

architector4@AGOGUS:~/Downloads/Cortex-Command-Community-Project$ git check-ignore -v external/sources/LuaJIT-04dca7911ea255f37be799c18d74c305b921c1a6/src/host/buildvm_asm.c
.gitignore:19:**/build*	external/sources/LuaJIT-04dca7911ea255f37be799c18d74c305b921c1a6/src/host/buildvm_asm.c

oh. this kills the luajit. suboptimal!

[Architector4]

oh wait i see this uses an entirely separate secondary build system at the same time, this explains why this repo prefers keeping all dependency code inside lmao

[Architector4]

aigh i have no idea what i'm doing 👍

i'm not installing windows and visual studio for this hell naw lmao

[HeliumAnt]

Yeah I love the wrapdb, but it's just not really compatible with our workflow sadly. Mostly due to the dual build systems.
We can't use system luajit either since we use some luajit internals and those are not stable across versions and not exposed in system headers.
Though it is high time we update dependencies, since they haven't been updated since before pre6

Better option would be another dependency manager like vcpkg, which is compatible with multiple build systems.

[Architector4]

Worst part is, I feel like I'm very close here. There's probably like one button or checkbox someone has to click within Visual Studio in project settings then save and git push and it'll be all nice. ARGH

[HeliumAnt]

Nope, it's literal hell to build luajit for windows. Though if the meson windows build is working now, then it's significantly easier and I can push the binaries for you

[numanair]

Compiling this pr on Windows it was complaining it couldn't find sed. Putting a Windows build of sed in my path and it compiled. Not sure if that helps?

[Architector4]

lemme try something cursed........................ lmao

[Architector4]

wait why am i-

this isn't a failue with building luabind why i'm focused on luabind lmao

[Architector4]

I MADE A TYPO IN SEARCH/REPLACE IN RTEA.VCXPROJ OOPs

[Architector4]

...it got farther i guess, i'm probably in the right direction :3

[HeliumAnt]

btw I'd like to take this over, there's a bunch of extra stuff to do to keep this maintainable (unless you want to commit to keeping this alive for a while). If you do it as you currently do, this will be a maintainance nightmare from version mismatches and especially keeping the windows build working.

[Architector4]

...oh right, old luajit also had a vcxproj and stuff

i should just copy that over probably

[Architector4]

btw I'd like to take this over, there's a bunch of extra stuff to do to keep this maintainable (unless you want to commit to keeping this alive for a while). If you do it as you currently do, this will be a maintainance nightmare from version mismatches and especially keeping the windows build working.

oh sorry, didn't notice this

let me fool around a little here please; if it turns out to be a problem, i assume you can merge from the first new commit in this branch or i can force push back to it or something?

[HeliumAnt]

that's totally fine, I meant that as a heads up, not immediate. Once you're done I'll probably tack on some extra to help keep it working (probably some CI stuff so this can stop needing to be done manually)(also this needs a major refactor of the windows build env to make it viable). We need dependency management, so any start is greatly appreciated.

[Architector4]

We need dependency management, so any start is greatly appreciated.

...To be frank, if I were to manage this codebase I'd nuke all this msbuild crap from orbit; there's still Meson building for Windows and having two package managers seems (and currently is!) a huge hindrance to this lmao

[HeliumAnt]

believe me I would have, problem is just you're now one of two people against almost literally all other contributors.

[Architector4]

blergh

also i think i found the current issue:

The codebase before this patch has the file external/sources/LuaJIT-2.1/src/luajit.h. This patched codebase has a file there called luajit_rolling.h, with a curiously simple diff:

diff --git a/tmp/LuaJIT-2.1/src/luajit.h b/external/sources/LuaJIT-04dca7911ea255f37be799c18d74c305b921c1a6/src/luajit_rolling.h
index 31f1eb1f5..2d04402c1 100644
--- a/tmp/LuaJIT-2.1/src/luajit.h
+++ b/external/sources/LuaJIT-04dca7911ea255f37be799c18d74c305b921c1a6/src/luajit_rolling.h
@@ -1,7 +1,7 @@
 /*
 ** LuaJIT -- a Just-In-Time Compiler for Lua. https://luajit.org/
 **
-** Copyright (C) 2005-2022 Mike Pall. All rights reserved.
+** Copyright (C) 2005-2023 Mike Pall. All rights reserved.
 **
 ** Permission is hereby granted, free of charge, to any person obtaining
 ** a copy of this software and associated documentation files (the
@@ -30,10 +30,10 @@

 #include "lua.h"

-#define LUAJIT_VERSION         "LuaJIT 2.1.0-beta3"
-#define LUAJIT_VERSION_NUM     20100  /* Version 2.1.0 = 02.01.00. */
-#define LUAJIT_VERSION_SYM     luaJIT_version_2_1_0_beta3
-#define LUAJIT_COPYRIGHT       "Copyright (C) 2005-2022 Mike Pall"
+#define LUAJIT_VERSION         "LuaJIT 2.1.ROLLING"
+#define LUAJIT_VERSION_NUM     20199  /* Deprecated. */
+#define LUAJIT_VERSION_SYM     luaJIT_version_2_1_ROLLING
+#define LUAJIT_COPYRIGHT       "Copyright (C) 2005-2023 Mike Pall"
 #define LUAJIT_URL             "https://luajit.org/"

 /* Modes for luaJIT_setmode. */
@@ -76,4 +76,5 @@ LUA_API const char *luaJIT_profile_dumpstack(lua_State *L, const char *fmt,
 /* Enforce (dynamic) linker error for version mismatches. Call from main. */
 LUA_API void LUAJIT_VERSION_SYM(void);

+#error "DO NOT USE luajit_rolling.h -- only include build-generated luajit.h"
 #endif

...i can't help but want to do the obvious cursed thing :D

[Architector4]

...also edited a .gitignore in there to match the current development branch's .gitignore there lmao

in my defense i'm merely replicating the cursedness already present in the development branch

[HeliumAnt]

don't. when using the build system correctly luajit.h will just be generated. Do not work around configurated headers even if it works initially since it will probably break things. Especially do not use generated headers from other platforms

[Architector4]

don't. when using the build system correctly luajit.h will just be generated. Do not work around configurated headers even if it works initially since it will probably break things. Especially do not use generated headers from other platforms

see, this is reasonable advice,

but i gave up all hope on reasonable advice when i saw that a luajit.h is already committed to the development branch and is infact not generated

furthermore, this latest CI error i'm getting here is because it fails to find the precompiled binaries for msbuild i guess??? that are also currently committed to the development branch: https://github.com/cortex-command-community/Cortex-Command-Community-Project/tree/2906eb86ddf1a41f4526fb0a4142bcd2c7c37b75/external/sources/LuaJIT-2.1/_Bin

i wouldn't be surprised if the current CI for the development branch is alive purely because of those precompiled binaries

at this point, for cursedness parity, it seems the last step necessary for everything here to work is for someone to do the same thing and precompile and commit those from latest LuaJIT here instead..........

.....or just abandon this branch's AND the current development branch's msbuild setup as too cursed and indeed redo it from ground up to not use precompiled binaries directly in repo lmao

[Architector4]

but yeah,

i COULD commit those ancient precompiled binaries into my branch too, but that would defeat the purpose of this branch for this build system

and i can't build the new ones from here since i'm on Linux

so yeah, i'm giving up on this, feel free to salvage whatever tricks or knowledge you need, feel free to close this and make your own separate PR based on this mess, or whatnot else lmao

[HeliumAnt]

Ugh luajit wrap isn't uptodate either. It's definitely newer, but not by that much (the meson files are much better tho)