Megapahit's fork of the Second Life viewer. https://megapahit.org/viewer.git/atom?h=26.1.1 2025-12-04T08:48:50Z 2025-12-04T08:48:50Z Erik Kundiman erik@megapahit.org 2025-12-04T05:58:12Z urn:sha1:e3a35af2c676fb211ff7d01a79eb1a3299bc82f3 2025-10-25T12:03:33Z Erik Kundiman erik@megapahit.org 2025-10-23T04:00:12Z urn:sha1:ab9976389fe5e4c254d3eb2c39fd2dff083d8d2d 2025-10-22T12:46:36Z Hecklezz tj8@live.com.au 2025-10-22T09:27:51Z urn:sha1:ab3106d58e2abe9fc3a9e74ac20ada9ca46a7f46 2025-10-16T16:44:18Z Ansariel ansariel.hiller@phoenixviewer.com 2025-10-14T13:15:24Z urn:sha1:790c52f3fdd6f326d36cd329d6090207c59d3cc8 With the update of APR to versoin 1.7.5., we have to deal with an erroneous check for the definition of __attribute__ added to the APR head file apr.h: The additional check for the definition of __has_attribute is nonsense as it is a C++ internal macro to check for the existance of certain attributes, however it has nothing to do with __attribute__ used in this context. Since __attribute__ is not defined in MSVC, the modified, erroneous check now causes said definition becoming missing, resulting in a huge amount of "this declaration may not have extern 'C' linkage" errors within in MSVC. This change utilizes CMake to patch the extracted APR header file, restoring the original version of the check. 2025-10-01T08:56:56Z Erik Kundiman erik@megapahit.org 2025-09-29T08:29:19Z urn:sha1:a954d290674db08ecaf3c1e6484a0cb6647b88b5 2025-06-03T09:51:57Z Erik Kundiman erik@megapahit.org 2025-06-03T09:51:57Z urn:sha1:a1d368a4528585d694340858939a7b2de35d7481 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-27T11:52:04Z Erik Kundiman erik@megapahit.org 2025-04-27T11:52:04Z urn:sha1:7cd7110c3b29ce74b1abe0cf307015e49199d766 Simpler. 2025-02-11T10:04:06Z Rye rye@lindenlab.com 2025-02-02T12:08:40Z urn:sha1:7bba6b835f2a64367399931b06597046b6f9e004