* fix FastDebug QtFRED linking the debug CRT
FastDebug builds in the DLL-runtime tree (used whenever qtFRED is
enabled) compiled with /MDd and, since #7450, linked Qt's debug
libraries. Both import ucrtbased.dll, MSVCP140D.dll and
VCRUNTIME140D.dll, which Microsoft does not license for redistribution,
so end users could not run the FastDebug qtFRED shipped in nightlies
and releases. Static Qt is ruled out by the LGPL, so the only shippable
shape is the release CRT plus release Qt.
On MSVC, _DEBUG is the CRT's own contract: /MTd and /MDd define it
themselves, and the STL headers select msvcprtd.lib and
_ITERATOR_DEBUG_LEVEL=2 from it. Stop force-defining it for FastDebug
on MSVC; the engine keys its debug behaviour on NDEBUG, and the few
_DEBUG guards in code/ are switched to NDEBUG so they keep working.
The static tree is unchanged: /MTd still defines _DEBUG there.
Fixes#7915
Co-Authored-By: Claude Fable 5.1 <[email protected]>
* derive the MSVC runtime choice once
The "DLL runtime or not" condition was spelled out in the toolchain and
twice in fred2 with "keep in sync" comments, and gtest_force_shared_crt
and antlr4's WITH_STATIC_CRT had already drifted: they only looked at
MSVC_USE_RUNTIME_DLL, so a qtFRED tree with tests enabled would have
asked both for the static CRT. That is harmless today only because our
flag strings carry no literal /MD for them to rewrite.
Compute FSO_MSVC_RUNTIME_DLL once in toolchain-msvc.cmake and use it
everywhere. InstallRequiredSystemLibraries deliberately stays keyed on
MSVC_USE_RUNTIME_DLL: the qtFRED deploy ships no compiler runtime.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
* remove FastDebug runtime leftovers
The /MD -> /MDd substitution on the FastDebug flag strings has done
nothing since the runtime moved to CMAKE_MSVC_RUNTIME_LIBRARY: the
Release flags it copies contain no runtime switch. The commented-out
_ITERATOR_DEBUG_LEVEL=0 lines for gtest and the OpenXR loader belong to
the scheme #7450 removed from the toolchain.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
* use the release CRT for all FastDebug builds
Microsoft's documentation marks the static debug libraries (libcmtd,
libucrtd, libvcruntimed) "Not redistributable" and states that debug
versions of an application may only be copied to machines used for
testing, and the license grants distribution rights only for code on
the REDIST list, which contains no debug library in any form. So the
statically linked FastDebug game and FRED2 are no more shippable than
the /MDd qtFRED was.
Link every FastDebug build against the release runtime. The engine's
debug behaviour keys on NDEBUG, which FastDebug still leaves undefined,
so asserts, warnings and mprintf are unaffected; only the debug CRT's
heap checking goes, and that remains available in Debug builds. FRED2's
static MFC library follows the CRT: the debug variant requires the debug
runtime.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
* keep the debug icon, version flag and FRED2 asserts without _DEBUG
The resource compiler only ever sees the explicit definitions, so with
_DEBUG no longer defined for FastDebug the game lost its debug icon and
both editors lost the VS_FF_DEBUG version flag. Key those on NDEBUG,
which FastDebug still leaves undefined.
FRED2 also used MFC's ASSERT, VERIFY, ASSERT_VALID and TRACE0, which are
all compiled out without _DEBUG. Convert them to the FSO equivalents
FRED2 already uses nearly everywhere else: Assert, Verify, a null check
in place of ASSERT_VALID (AssertValid only exists in debug MFC), and
mprintf. The AssertValid/Dump overrides and DEBUG_NEW stay under
_DEBUG, as they must.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
---------
Co-authored-by: Claude Fable 5.1 <[email protected]>
As discovered by WouterSmits, campaigns with periods in their filenames caused issues with FSO's campaign handling. Specifically, in The Babylon Project, the EA-Minbari war v1.0.fc2 campaign would not save progress because FSO expected EA-Minbari war v1.fc2 in certain places. This is because the `_splitpath()` function attempted to remove an extension from a filename that already had it removed. For most campaigns this did not matter, but WouterSmits found a campaign where it did.
To solve this, there is now a new `util::get_file_part()` function to remove the path without removing the extension. This replaces `_splitpath()` for campaign files, as well as the similar `clean_filename()` and `GetFilePart()` functions in other places. All code paths were inspected for any chance of inadvertent extension adding, and Assertions were added to verify future code. The only potential problem area was `player:loadCampaignSavefile()` which now pre-removes the campaign extension if needed.
added myself to credit
killed some of the stupid fscking warnings (including doing some casting and commenting out unused vars in the graphics modules)
Release builds should have warning level set no higher than 2 (default is 1)
Why the hell are we getting warning's about function selected for inline expansion... (killing them with warning disables)
FS2_SPEECH was not defined (source file doesn't appear to capture preproc defines correctly either)
