Commit Graph
2 Commits
Author SHA1 Message Date
76eda883a5 build Lua from vendored source instead of the prebuilt lua51.lib
The tree carried two prebuilt Lua static libraries and a copy of the Lua
public headers. lua51.lib is 5.1.2 and matched the headers; lua51.vc9.lib
is 5.1.4 and was dead weight — it came second in Ja2_Libraries, so the
linker resolved every Lua symbol out of lua51.lib and never pulled an
object from it. Just as well, since it asks for /DEFAULTLIB:MSVCRT while
we build /MT.

ext/lua-5.1.5 is the upstream tarball unmodified, built as lua51 the way
the other vendored libraries are, and its src directory replaces lua/ as
the home of lua.h, luaconf.h, lauxlib.h and lualib.h. Those four headers
were stock 5.1.2 retabbed, so 5.1.5 is bugfix-only against what the game
compiled against; the bytecode format is unchanged across 5.1.x and every
script under gamedir is plain source anyway. lua/lua.hpp had no includers
and returns to etc/ where upstream keeps it.

/SAFESEH:NO goes with it. Its two stated reasons were lua51.lib and the
smackw32 import library, and both are now gone: every remaining prebuilt
static library is SAFESEH-clean (libexpatMT.lib 5 of 5 members with
@feat.00 = 0x1, RakNetLibStatic.lib 79 of 79), and lld-link emits a
3155-entry SEHandlerTable without it.

The /MT comment blamed the wrong library. lua51.lib carried no linker
directives at all; RakNetLibStatic.lib is what pins us to the static
runtime, with /DEFAULTLIB:LIBCMT and /DEFAULTLIB:libcpmt.

Verified by building all four applications in Debug and Release, and by
linking the tarball's own lua.c against our lua51.lib with the build's
clang-cl flags and running it under Wine: 5.1 stdlib, GC, coroutines and
the x86 __asm fld/fistp lua_number2int fast path all behave. The game
itself could not be launched here — this checkout's gamedir has loose
Data directories but no SLF archives, so VFS aborts on Data\Ambient.slf
long before any script runs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 13:25:35 -03:00
Marco Antonio Jaguaribe Costa 8609944467 Add a CMake build
Tried to stay as close as possible to ja2_2019.sln

On Visual Studio 2022 just Project -> CMake Settings for Ja2, add
the x86 configurations you want and press F7.

Below shows how the -DLanguages -DApplications switches work, If you don't
set them, the CMakeCache.txt of them will be set to ENGLISH and JA2,
respectively:

cmake [...] // nothing set, configure just JA2_ENGLISH.exe by default
cmake [...] -DApplications="JA2UB" // configures just Unfinished Business
cmake [...] build -DApplications="JA2UB;JA2UBMAPEDITOR" // Unfinished Business and UB Map Editor
cmake [...] build -DApplications="JA2UB;JA2MAPEDITOR;ALL" // ALL is in the list, configures every application
cmake [...] build -DApplications="JA2MAPEDITOR;DeathStranding" // fatal error: DeathStranding not an application

cmake [...] -DLanguages="GERMAN" // configures just German targets
cmake [...] build -DLanguages="GERMAN;ENGLISH" // German and English
cmake [...] build -DLanguages="GERMAN;ENGLISH;ALL" // ALL is in the list, configures every language
cmake [...] build -DLanguages="ENGLISH;ESPERANTO" // fatal error: ESPERANTO not supported
2023-01-14 02:08:39 -03:00