CMAKE_SYSTEM_VERSION returns 10.0 on my Win7 VM because I'm manually
specifying that version.
On Win10 with VS2022, it returns 10.0.22621.
On both systems, CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION returns
10.0.22621.0, regardless of whether or not CMAKE_SYSTEM_VERSION is
manually set.
rp-libfmt.h:
- Make FSTR() a no-op if building as C++20, since fmt::format() can do
its own compile-time checking using `consteval` without FMT_STRING().
- Add FRUN() annotations to all gettext-translated strings. This is
needed in order to bypass the automatic compile-time format checking
when using C++20.
- Add FSTR() annotations to some format strings where it was missing.
WiiUFstPrint: Change some fmt::print() that don't actually use formatting
back to fputs().
CMake Warning (dev) in CMakeLists.txt:
A logical block opening on the line
/home/david/programming/rom-properties/CMakeLists.txt:6 (IF)
closes on the line
/home/david/programming/rom-properties/CMakeLists.txt:8 (ENDIF)
with mis-matching arguments.
This warning is for project developers. Use -Wno-dev to suppress it.
clang complains about namespace pollution in generated moc_*.cpp files:
In file included from src/kde/kf5/kfilemetadata_rom-properties-kf5_autogen/mocs_compilation.cpp:2:
src/kde/kf5/kfilemetadata_rom-properties-kf5_autogen/BKZOEHIFDQ/moc_ExtractorPluginKF5.cpp:1082:17:
warning: using namespace directive in global context in header [-Wheader-hygiene]
1082 | using namespace RomPropertiesKF5;
| ^
Setting CMP0151 tells AUTOGEN to add the include paths using -isystem,
which tells clang it shouldn't print warnings about these files.
Currently used as a header-only build. Will eventually be changed to
build a DLL for Windows and Mac OS X.
Other changes needed to get the Windows version to build with libfmt:
Add #include <fmt/xchar.h> to some files for full wchar_t support
in libfmt. Otherwise, errors like this appear:
src\amiibo-data\amiiboc.cpp(175,8): error C2665: 'fmt::v11::print': no overloaded function could convert all the argument types
extlib\libfmt\include\fmt\base.h(2925,17): message : could be 'void fmt::v11::print<TCHAR*&>(FILE *,fmt::v11::fstring<TCHAR *&>,TCHAR *&)'
src\amiibo-data\amiiboc.cpp(175,8): message : 'void fmt::v11::print<TCHAR*&>(FILE *,fmt::v11::fstring<TCHAR *&>,TCHAR *&)': cannot convert argument 2 from 'wmain::<lambda_1>::()::FMT_COMPILE_STRING' to 'fmt::v11::fstring<TCHAR *&>'
src\amiibo-data\amiiboc.cpp(175,22): message : No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
extlib\libfmt\include\fmt\base.h(2908,17): message : or 'void fmt::v11::print<wmain::<lambda_1>::()::FMT_COMPILE_STRING,TCHAR*&>(fmt::v11::fstring<wmain::<lambda_1>::()::FMT_COMPILE_STRING,TCHAR *&>,wmain::<lambda_1>::()::FMT_COMPILE_STRING &&,TCHAR *&)'
src\amiibo-data\amiiboc.cpp(175,8): message : 'void fmt::v11::print<wmain::<lambda_1>::()::FMT_COMPILE_STRING,TCHAR*&>(fmt::v11::fstring<wmain::<lambda_1>::()::FMT_COMPILE_STRING,TCHAR *&>,wmain::<lambda_1>::()::FMT_COMPILE_STRING &&,TCHAR *&)': cannot convert argument 1 from 'FILE *' to 'fmt::v11::fstring<wmain::<lambda_1>::()::FMT_COMPILE_STRING,TCHAR *&>'
src\amiibo-data\amiiboc.cpp(175,14): message : No constructor could take the source type, or constructor overload resolution was ambiguous
src\amiibo-data\amiiboc.cpp(175,8): message : while trying to match the argument list '(FILE *, wmain::<lambda_1>::()::FMT_COMPILE_STRING, TCHAR *)' [build.vc17_64\src\amiibo-data\amiiboc.vcxproj]
Files modified for xchar.h:
- amiibo-data/amiiboc.cpp
- libromdata/stdafx.h (needed by WiiUPackage)
- libromdata/tests/RomHeaderTest.cpp
NOTE: Only included on Windows. xchar.h was added in libfmt-8.0.0,
which was first added (in Ubuntu LTS releases) in Ubuntu 20.04.
It's not needed on Linux, anyway.
New option USE_INTERNAL_FMT to force the use of the internal copy of
libfmt on Linux, for testing purposes. (...and also for Ubuntu 16.04)
- TODO: Maybe use it on 18.04, etc. for improved performance?
This will replace printf()-style functions in most cases, and will
replace all uses of rp_sprintf() and related.
NOTE: We need to use FMT_STRING() [which we're abbreviating FSTR] if
compiling without C++20 support; otherwise, string format checking won't
be done. We're not targetting C++20 at the moment.
Also, string format checking can't be done when using gettext. This also
applied to printf(), so it's not a big deal per se.
NOTE: Support for C++-style format strings (std::print) was added in
gettext-0.22, so gettext-0.22 will be required in order to update the
.pot and .po files.
FIXME: libfmt has its own "PACKED" definition, which conflicts with our
own. We should rename our "PACKED" to "RP_PACKED".
TODO: Add an internal copy of libfmt for Windows.
While the code itself supports all three API versions, we're only
supporting installing into a single version directory. Added
auto-detection to detect what version is installed, plus a manual
override using TRACKER_INSTALL_API_VERSION to explicitly specify
which version to use.
Ubuntu versions and Tracker API versions:
- 16.04: v1
- 18.04: v2
- 20.04: v2
- 22.04: v3
- 24.04: v3
[debian] rules: Explicitly specify the API version so we don't need to
install the Tracker packages when building.
Ubuntu 16.04 has CMake 3.5, so we can target that as the minimum
version. Also, recent CMake versions (3.27+) have started printing
warnings if the minimum is less than 3.5.
CMake Deprecation Warning at CMakeLists.txt:2 (CMAKE_MINIMUM_REQUIRED):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winbase.h(8816,5): warning C5105: macro expansion producing 'defined' has undefined behavior
C:\Program Files (x86)\Windows Kits\8.1\Include\um\oaidl.h(473,17): warning C5103: pasting '/' and '/' does not result in a valid preprocessing token
C:\Program Files (x86)\Windows Kits\8.1\Include\shared\wtypes.h(742,1): message : in expansion of macro '_VARIANT_BOOL'
C:\Program Files (x86)\Windows Kits\8.1\Include\um\oaidl.h(473,17): error C2059: syntax error: '/'
Force C99 when compiling with MSVC for now.
CMake 3.1 added CMAKE_<LANG>_STANDARD, which allows CMake to determine
what flags are needed to select a particular language version.
Set it to C17 and C++17. Previously, we were using C11 and C++11,
though gcc11 switched the default C++ version to C++17. The custom
macro handled this by not adding flags for C++, but it still added
the C11 flag, which prevented use of C17.
No code size differences were observed when compiling on gcc-13.2.0
with CMAKE_<LANG>_STANDARD.
BUILD_XFCE is an option; BUILD_GTK2 is not.
We should probably get rid of BUILD_GTK2 entirely, since I'm not planning
on adding support for GNOME 2 Nautilus anytime soon.
Also, don't attempt to build rom-properties-glib if none of the GTK UI
frontends are being built.
Fixes CMake issues when building on KDE Neon. (KF6 testing)
ARM64EC is always checked before ARM64 (in case both are defined for
some reason) and AMD64 (because MSVC defines _M_AMD64 on ARM64EC builds).
CPUInstructionSetFlags.cmake: Set both CPU_arm64 and CPU_arm64ec.
TODO: Does the Win32 manifest processor architecture change for ARM64EC?
DirInstallPaths.cmake: Set TARGET_CPU_ARCH. This is now used by the
summary at the end of the root CMakeLists.txt.
i18n.c, DelayLoadHelper.c: Add ARM64EC.
CMakeLists.txt: Print ${TARGET_CPU_ARCH}.
This tells CMake to not re-link executables if a shared library's
implementation has changed but its headers haven't changed.
Should improve build performance when modifying a .cpp file in
libromdata, since it won't have to re-link all of the UI frontends
and unit tests.
Some distributions install documentation using distro-specific build
scripts, so add an option to allow our documentation install to be
disabled.
Specify -DINSTALL_DOC=OFF on the CMake command line.
CMake 3.2 added FindIntl.cmake for gettext.
CMake 3.4 added STRING(APPEND), which is used by Qt5's CMake files.
Update the toplevel project's CMake requirement and remove the
requirements on all lower-level projects, except for third-party
libraries.
Reported by @DankRank.
This will add a "ROM Properties configurator" entry to the applications
menu on most Linux desktop environments.
TODO:
- Custom rom-properties icon instead of "media-flash".
- GTK+ rp-config implementation.
Fixes#295: [Feature Request] rp-config launcher
Reported by @Amnesia1000.
I chose MiniLZO instead of regular LZO because we only need to be able to
decompress LZO1X blocks.
[libromdata] CisoPspReader: Don't call lzo_init() if this JISO isn't
actually using LZO. Otherwise, if the DLL is missing on Windows, the
program will crash.
It has a unique header, but the index entries table is similar to the
other formats. It does *not* set the high bit to indicate NC; instead,
it uses the same method as CISOv2, where the compressed block size
matches the uncompressed block size.
Compression algorithm is lzo1x.
TODO:
- JISO supports NC areas. Figure this part out.
- Add LZO to extlib.
ZISO is basically CISO v0/v1 but with LZ4 instead of zlib.
CISO v2 can use either zlib or LZ4 on a per-block basis.
[cmake] Added LZ4 checks.
- TODO: Add an internal copy of LZ4.
This option now controls seccomp(), Win32 low integrity processes,
and OpenBSD pledge() and tame(). It's recommended to keep it enabled
everywhere, though on Linux it may need to be disabled if a glibc
update breaks things due to new syscalls.
appveyor.cmd, travis.sh: Set ENABLE_EXTRA_SECURITY.
MiniZip 2.10.0 added support for zstd as a compression method, so we
should support it.
Note that a system version of zstd is preferred on Linux systems.
Enabled the MiniZip test tools for manual builds only. Info-ZIP hasn't
been updated in a while, so I'm going to use the MiniZip test tools to
compress ZIP archives using zstd.
Enabled MiniZip compression in order to compress stuff using the minizip
test program.
mz_strm_zstd.c: FIXME: Compression level doesn't work. Hard-coded the
maximum compression level for now.
The variables have been (mostly) renamed to GTK2, though the user-facing
variable is still BUILD_XFCE, and it shows "XFCE" in the UI_FRONTENDS
status message.
I don't know if I'll be adding support for old GTK+ 2.x Nautilus
versions...
