Megapahit's fork of the Second Life viewer. https://megapahit.org/viewer.git/atom?h=26.4 2026-07-31T11:29:02Z 2026-07-31T11:29:02Z Erik Kundiman erik@megapahit.org 2026-07-31T11:29:02Z urn:sha1:7e47eff5042c2fb897c8eee1219889a84ca3bf36 so no need for USE_FLATPAK, and just maybe there are some other platforms that use this runtime as the distro info. 2026-06-22T03:25:21Z Erik Kundiman erik@megapahit.org 2026-06-22T00:34:39Z urn:sha1:ee87dd9f21e0dcd5a2f3a78586e5ae5d2ba592d5 Still uses prebuilt GLU, could be improved by using the glu shared module. Still uses prebuilt OpenAL, could be improved by separating the ALUT dependency (which isn't available on the runtime) from it, so we could use runtime's OpenAL. Still uses prebuilt LibXML2, could be improved by separating the Minizip & ColladaDOM from it (which aren't available on the runtime) from it, so we could use runtime's LibXML2 but have ColladaDOM built against it (and a still non-runtime Minizip). Still uses FLTK 1.3, when I tried using 1.4, it still had linking errors (might need to just add Cairo libraries to the target_link_libraries). VLC plugins are installed in vlc/plugins path relative to the vlc & vlccore libraries, the way they are in the distro I got the binaries from (Debian), cause I think it's the libraries that are compiled with that path. Still uses prebuilt dependencies in general, could be improved by having them as modules to be built. _FORTIFY_SOURCE needs to be skipped to avoid redefinition cause Flatpak build system already defines it. The conditionals for deciding installation paths need to be reorganised to accomodate installation that doesn't require an encapsulating namespace (because the installed files are already encapsulated in the app sandbox). The library directory naming scheme used here is lib64. The libGLESv2.so & libvulkan.so.1 installed are still copies, not links yet, because I'm still not familiar yet with the runtime hierarchies (they might reside just in /usr/lib/x86_64-linux-gnu). 2026-06-14T05:58:07Z Erik Kundiman erik@megapahit.org 2026-06-14T05:58:07Z urn:sha1:582462ba123f55cc67f006fe0ecbfbba81311f84 so we don't have to keep 1.0.1 on vcpkg or MacPorts around any more (the last version they compile with, in the code's current state). 2026-05-19T11:08:57Z Erik Kundiman erik@megapahit.org 2026-05-19T11:08:57Z urn:sha1:9fb839403f7b6665a26018e5987aecfc7f0921bc 2025-05-27T02:01:21Z Erik Kundiman erik@megapahit.org 2025-05-27T02:01:21Z urn:sha1:7ecde89008f9ed39c357b606d3bc231ba4360ee2 I happen to be using just Git Bash for convenience for running the commands on the Windows build instructions, hence the build folder pattern to be ignored from the result of running `uname -s` there. The instructions omit the part where you install vcpkg and set the VCPKG_ROOT environment variable, cause it depends on where you install vcpkg to your liking, but the next commands will rely on that variable being set correctly. The CMake used here is MS VS 2022 Community Edition's one, since it will know where the C++ compiler is. $VCPKG_ROOT/downloads/tools/msys2/21caed2f81ec917b/mingw64/bin is where pkg-config.exe can be found. $VCPKG_ROOT/installed/`uname -m|sed 's/86_//'`-windows/tools/libxml2 is where xmllint.exe can be found (from libxml2[tools]). PKG_CONFIG_LIBDIR and PYTHON environment settings are pretty self-explanatory. The flags set on LL_BUILD are now for Visual C++ and not MinGW(64)'s GCC or Clang any more, and copied from most of the flags in the variables file from LL's build-variables repo. vcpkg's apr & apr-util packages don't seem to install their .pc files, hence the manual target_include/link_directories/libraries settings, relying on some automatically generated INTERNAL CMake variable called prefix_result. vcpkg's Boost needs the same treatment, plus some suffix. We still use LL's prebuilt libs for OpenSSL, libcurl and WebRTC. Actually too for ColladaDOM for now, but we prepare Windows ColladaDOM self-building for later. For GLM and Meshoptimizer too, it's just the checking that's skipped otherwise it would fail (but the vcpkg packages can be used). Visual C++ doesn't recognise the no-deprecated-declarations compile option. On Visual C++, the macro to denote x86-64 seems to be _M_X64 (if not added there, it would try to find sse2neon :)) We still aren't using Autobuild here for Windows either, hence the FALSE-d viewer_manifest.py based file bundling. 2025-05-13T02:22:54Z Erik Kundiman erik@megapahit.org 2025-05-13T02:22:54Z urn:sha1:f5ab6e11f13699c03a696611f67f8384434130a1 but the fact that we keep on using as many system libraries as we can (and only resort to other sources in certain cases), hasn't changed, of course. Also stop having to set USE_AUTOBUILD_3P to OFF. Lines are reindented, and when a system library can be found for a dependency, then that should be the way. If later we find out that using some other way is better, than stick to that. So, one option at a time, whichever is best for the situation. GLEXT hasn't been used, and in order to be not having to hack its .cmake file, we bypass it and refer to GLH (which is still used) right away in LLWindow. CMake commands that need to be bypassed, if it's a one-liner then it's just commented out, but if it's multiple lines, then scope them with if (FALSE) to minimise difference. 2025-04-07T04:09:57Z Erik Kundiman erik@megapahit.org 2025-04-07T03:52:31Z urn:sha1:415bfb74fd52b200f21031e78a4ca9fd5e595978 Since the last merge, the prebuilt version has been used for all Megapahit platforms, when some should've used the system version instead, as instructed. And then, not all Linux distros don't have sufficient version of GLM on their repos, some do have and have already been instructed to install system GLM anyway. So the distros that still have insufficient version of GLM (0.9.9.8 instead of the necessary 1.0.1) are Debian, Ubuntu and openSUSE Tumbleweed, while other distros and OSes have GLM 1.0.1. 2024-08-19T14:35:01Z Erik Kundiman erik@megapahit.org 2024-08-19T12:36:17Z urn:sha1:b7afbe59c42a3e6e92f712153172364f4ebaa5e2 2024-07-29T07:29:20Z Erik Kundiman erik@megapahit.org 2024-07-29T07:29:20Z urn:sha1:29526f5307c0035c6b2b9e07266808b91796dc2b The viewer codebase requires GLM 1.0.x, not 0.9.x. 2024-07-28T00:26:38Z Erik Kundiman erik@megapahit.org 2024-07-28T00:26:38Z urn:sha1:630a1197d219e57098236913bbd464d6b03f2a6d I had to use find_package here directly because somehow our "different" use_system_binary wouldn't set glm_FOUND to true, even though CMake found the package.