summaryrefslogtreecommitdiff
path: root/indra/cmake
AgeCommit message (Collapse)Author
4 daysUse MacPorts' Boost 1.88 instead of its Boost 1.87Erik Kundiman
Now that MacPorts' newest Boost version is 1.88.
2025-08-15Merge branch 'main' into 2025.06Erik Kundiman
2025-08-11Supported Debian amd64 is now 13.0 (current stable)Erik Kundiman
OpenAL and LL's WebRTC now break CEF too just like on many other supported distros. Same as Ubuntu 24.04.2 when it comes to not yet compatible newer Pipewire, but OpenJPEG 2.5.3 (unlike 24.04.2 which is still at 2.5.0). The libminizip1 package name is also fixed here for Ubuntu.
2025-08-11FMOD has been upgraded from 2.02.29 to 2.02.30Erik Kundiman
2025-08-08Merge tag 'Second_Life_Release#55f1c8b9-2025.06' into 2025.06Erik Kundiman
2025-08-05#4470 Adjustments and Mac build fixesAndrey Kleshchev
2025-08-05#4470 Plug in Discord SDK packageAndrey Kleshchev
2025-07-31Rich Presence support using Discord Social SDK (#4457)Erik Kundiman
* Rich Presence support using Discord Social SDK Download DiscordSocialSdk-1.4.9649.zip from https://discord.com/developers/applications/1394782217405862001/social-sdk/downloads Add -DUSE_DISCORD:BOOL=ON to your cmake line. The Discord app needs to be set to be a public client in the OAuth2 tab. All Discord-related code are contained within one file, llstartup.cpp, and other classes access it through some opaque layer, static functions, otherwise we'd get these "duplicate symbol" linking errors. * Move Discord-related code to llappviewer.cpp The doFrame is the one called over and over again, so running the Discord callbacks from there shouldn't have one extra function overhead, while running the Discord initialisation is only once so it's much more okay to have the extra function overhead there. * panel_preferences_privacy tabs Add tab and checkboxes for discord social SDK integration options to panel_preferences_privacy.xml * Shorten Discord-related local variable names * Connect to Discord now through privacy tab Now the access token is saved the way passwords are saved, but without a username, so we can have some persistence without having to implement an OAuth2 backend server cause we would have to store those tokens there anyway still, and it's just simpler to not go that way. Discord Social SDK doesn't have a helper for sending code to a custom server anyway, that we would have to have some asynchronous HTTP requestor ready. Show location check button gets enabled only when Discord integration is enabled, though it's not functioning yet. * Location for Discord Rich Presence Activity State I was going to use LLAgentUI::buildLocationString but there's no location format that shows only region and coords without having to have the parcel name empty, so I copied buildLocationString implementation in the case of LOCATION_FORMAT_NO_MATURITY but when the parcel name is empty. I had to make updateDiscordActivity check agent's ID and the existence of agent avatar pointer first before trying to set Activity Details or State, cause I like the "Show location" button be checkable not only after online when both the ID & pointer will have existed. I think this way is simpler than programmatically enabling the "Show location" button after the user is logged in. I put a trigger to Activity update somewhere after the user is logged in for now, not yet after a TP. The elapsed time gets reset whenever Activity is updated for now, but I'll try to make elapsed time extended instead. No Party for now, because I couldn't find a way to make a Party shown without showing its CurrentSize (I could still get away not showing its MaxSize by setting it to 0), so the State (location) is shown above the elapsed time, not on the right of it. I'll try to figure out to get some representative numbers for its CurrentSize & MaxSize next. Also no privacy on hiding the username for now, until the UI is ready. * Update Rich Presence location on region change I had to find a spot in source code where it doesn't cause a crash (it did in LLAgent::setRegion), but I'm not removing the one in llstartup.cpp because on login, the one in llviewermessage.cpp gets only the placeholder coords (10, 10, 10). * Show display name too on Discord Rich Presence Avatar name cache can be used right away upon login now after I moved the update call to the end of PRECACHE section in llstartup. * Show Discord Rich Presence Activity Party By setting CurrentSize to the number of people within chat radius, and MaxSize to the number of people within near range. * Call updateDiscordActivity too in Discord init so when the user enables the integration after being logged in, the init can show the name and location right away. * Discord Rich Presence: Hide name & connect to llappviewer.cpp Add option to show/hide avatar name in privacy panel & connect rich presense directly to llappviewer.cpp * Discord time elapsed not reset on region change Time elapses right after viewer launch even before login. Plus parameter name change in header to make it the same as in implementation. * Cache bool setting retrievals in updateDiscordActivity As suggested by Andrey Kleschev. getBOOL and getF32 are expensive, so using `static LLCachedControl<>` is the way to do it in llappviewer.cpp. * Check Discord creds existence before getting token as suggested by Andrey Kleshchev, anticipating external factors such as user moving settings from another PC. * Tracy visibility for looped Discord function calls As suggested by Andrey Kleshchev. They likely can get pricey so they need to be visible in the profiler. * Discord-related error handling/logging plus delay saving Discord credentials to only after the access token is successfully updated on Discord, and try to disconnect from Discord when the integration gets disabled regardless whether there are credentials to delete or not and whether there's an access token to revoke or not. * Use getAvatars already called for Discord Party numbers so we don't have to make any extra getAvatars calls just for this, as it's pricy in crowds, and we'll just be piggybacking `updateSpeakerList` and `updateNearbyList`. * Assemble Discord Activity Details only once by saving it to a static global string for reuse. * Remove updateDiscordActivity call in startup loop The State field (region & coords) is updated well enough without it now. * Rename handleDiscordSocial to toggleDiscordIntegration * Update Discord Activity only when integration is enabled No need to check setting for the status change callback one, because getting there would need to be connected to Discord first, which in turn needs the integration to be enabled first. --------- Co-authored-by: Secret Foxtail <remmy@megapahit.net>
2025-07-21Merge branch 'main' into 2025.05Erik Kundiman
2025-07-19Exclude Debian arm64 from WebRTCErik Kundiman
When WebRTC was compiled with the viewer, we got this: Fatal error in: ../webrtc/src/media/engine/adm_helpers.cc, line 39 last system error: 88 Check failed: 0 == adm->Init() (0 vs. -1) Failed to initialize the ADM. This commit hasn't included the additional preprocessor macro for the platform in indra/newview/llvoiceclient.cpp yet, because there's no such macro yet to distinguish such distro from any other GNU/Linux distro.
2025-07-18Merge branch 'main' into 2025.05Erik Kundiman
2025-07-12Rich Presence support using Discord Social SDKErik Kundiman
Download DiscordSocialSdk-1.4.9649.zip https://discord.com/developers/applications/1393451183741599796/social-sdk/downloads to your ~/Downloads folder. Add -DUSE_DISCORD:BOOL=ON to your cmake line. The authorisation is triggered by selecting Help > Discord Social. It seems that the user will need to do this every time they want Rich Presence support on the viewer while using Discord. The Discord app is still set to be a public client in the OAuth2 tab, I'm going to try to make it work with the app set to be a confidential client, next. All Discord-related code are contained within one file, llstartup.cpp, and other classes access it through some opaque layer, static functions, otherwise we'd get these "duplicate symbol" linking errors.
2025-07-08Debian arm64 can use system nanosvgErik Kundiman
cause it's available now on trixie.
2025-07-08Windows can use vcpkg nanosvgErik Kundiman
2025-07-08Turn NDOF back on for Windows x64Erik Kundiman
and don't rebuild NDOF on non x86-64 Linux when it's already installed.
2025-07-08NDOF support for non x86-64 LinuxErik Kundiman
2025-07-07Get the viewer installable on Debian arm64Erik Kundiman
The Debian version supported is 13 (trixie), because that's the version I could install on my M1, hence the Boost default version is 1.83 & we can use system's OpenJPEG 2.5.3. Somehow CMake's FindOpenGL wasn't effective, but we can get around this by setting the GL libraries paths when running cmake. Debian aarch64 suffers from the same problem Fedora aarch64 had when compiling libcurl, and it's assumed that it's Linux aarch64 thing. When trying to build ColladaDOM when building the viewer, it couldn't find Boost somehow, so building ColladaDOM is done in configuration stage instead. Upstream Variables.cmake is full of assumptions regarding architecture, and ARCH is used in many places already for Debian/Ubuntu, so we have to make sure ARCH is set with the correct value at the root level. Pipewire on trixie is also too new, so it's cancelled here. Some dependencies have the t64 suffixes on them, just like the currently supported Ubuntu (because I guess 24.04 *is*, based on trixie). The executable still crashes when launched on my M1, however, but we'll commit the progress so far for now.
2025-07-03Merge tag 'Second_Life_Project#bca9ba9b-glTF_Mesh_Import' into gltf_mesh_importErik Kundiman
2025-06-25Revert "Attempt to replace __cpuid, on arm64 using cpuinfo"Erik Kundiman
This reverts commit 32871ee579bfbd4828f7888550897f619fdfd9d7.
2025-06-23No NVAPI on Windows ARM64Erik Kundiman
2025-06-23Fix the vcpkg Boost libraries suffix on Win arm64Erik Kundiman
2025-06-23Revert "GLM_FORCE_NEON for Windows arm64 too"Erik Kundiman
This reverts commit 75012c4f0c0b852c8bfa0b5632bf82c82f240754. I realised I was in the wrong direction after I avoided the offending lines by setting GLM_FORCE_XYZW_ONLY, and then by setting GLM_FORCE_CXX_UNKNOWN, to end up with the same 16 __m128-related "too many initializers" errors, which I believe were just obscured by the 160 syntax errors, which are to be fixed in the next commit. I had already mentioned SSE2NEON being responsible for translating __m128, but I had forgotten that it was a different package from GLM, obviously, that __m128 was never GLM_FORCE_NEON's responsibility.
2025-06-19GLM_FORCE_NEON for Windows arm64 tooErik Kundiman
though there are still so many compile errors, but it should be in the right direction, cause firstly we can't let it use GLM_FORCE_SSE2 otherwise it would include x/emmintrin headers, and secondly, if none of the GLM_FORCEs is used then the errors are much fewer but related to __m128 which should be translatable by SSE2NEON (that's why I believe GLM_FORCE_NEON should be ON for Windows arm64 too).
2025-06-19Attempt to replace __cpuid, on arm64 using cpuinfoErik Kundiman
This commit is for getting rid of the compile error for now, we don't know yet if this will work correctly or not.
2025-06-15Make sure lib/release exists on Windows arm64Erik Kundiman
before using it for ColladaDOM library file, cause it seems that ColladaDOM is the first one that gets built on Windows arm64 before any other package gets installed and implicitly creating that folder.
2025-06-13FMOD has been upgraded from 2.02.28 to 2.02.29Erik Kundiman
2025-06-13Remove ../lib rpath from dullahan_host for allErik Kundiman
It's irrelevant on any distro anyway.
2025-06-12Put MSYSTEM_CARCH env setting check in parenthesesErik Kundiman
Parsing failed on macOS' CMake (could be MacPorts, could be the version) for some reason.
2025-06-12Use system (vcpkg) OpenSSL & cURL on Windows arm64Erik Kundiman
cURL is installed on arm64 cause there doesn't seem to be any easy way to build OpenSSL 1.1 for Windows arm64 (which LL's cURL fork depends on).
2025-06-12Exclude Windows arm64 from WebRTCErik Kundiman
Crow Misia's libwebrtc-bin, the one we've been relying on for WebRTC binaries, doesn't seem to be providing Windows arm64 binaries yet.
2025-06-10macOS 26 build changes (#4239)Jonathan "Geenz" Goodman
* Fix for VLAs now emitting warnings on Xcode 26, and AGL being removed from the SDK. Note: there was no warning or notice provided for AGL's removal. * Whitespace.
2025-06-07Fix ColladaDOM link error to Boost throw_exceptionErik Kundiman
in viewer linking stage on Windows. throw_exception is user defined (it's not picking up its definition from anywhere on Windows, at least when using vcpkg's Boost). (Link target) -> libcollada14dom23-s.lib(daeURI.obj) : error LNK2019: unresolved external symbol void __cdecl boost::throw_exception(class std::exception const &) (?throw_exception@boost@@YAXAEBVexception@std@@@Z) referenced in function void __cdecl boost::re_detail_500::raise_runtime_error<class boost::regex_error>(class boost::regex_error const &) (??$raise_runtime_error@Vregex_error@boost@@@re_detail_500@boost@@YAXAEBVregex_error@1@@Z) [C:\Users\erik\Documents\Megapahit\viewer\build-mingw64_nt-10.0-19045-x86_64\newview\megapahit.vcxproj]
2025-06-06Enable media plugins on WindowsErik Kundiman
Put the necessary files into place. But, none of them is working just yet.
2025-06-05Combine 2 ColladaDOM sed process in 1 executionErik Kundiman
and make the if, else, & endif styles more consistent.
2025-06-05Only Windows link to Boost JSON library fileErik Kundiman
Adding another library file to link means adding many more lines for other platform(s), at least for macOS with its bundling. It's much simpler to make the condition on 2 files.
2025-06-04No link to vcpkg absent Boost Regex library fileErik Kundiman
2025-06-04Fix vcpkg Boost JSON linking errorsErik Kundiman
The error was "definition of dllimport static data member not allowed", and not "definition of dllimport function not allowed" as mentioned in commit 2bf9d234aac30ed4a85282730da0ffc83acf9adf description. Basically there were about 5 offending files, and all had BOOST_JSON_REQUIRE_CONST_INIT in them. Not including json/src.hpp (that includes them among others), fixes those errors, but then there are definitions in them that are actually used by llsdjson. After doing so many searches, I came across this: https://stackoverflow.com/questions/3491990/c-definition-of-dllimport-static-data-member and just from the first paragraph in the accepted answer, I realised llsdjson can still have those definitions, just not from the offending headers, but by simply linking to Boost JSON compiled library instead.
2025-06-04Set ColladaDOM to refer to vcpkg BoostErik Kundiman
Turns out I couldn't repeat self-building ColladaDOM using SLv prebuilt Boost successfully, because of the zlib, minizip, libxml2 header directories search confusion, no matter how I tried tinkering with LL's ColladaDOM fork CXX_FLAGS and/or EXTRA_COMPILE_FLAGS settings. With vcpkg Boost, self-building ColladaDOM in the viewer CMake configuration stage goes smoothly (compiling ColladaDOM on Windows could take a while, though.. at least on my system).
2025-06-04Revert "Use LL's prebuilt Windows Boost for now"Erik Kundiman
This reverts commit 2bf9d234aac30ed4a85282730da0ffc83acf9adf.
2025-06-04Self-build ColladaDOM on WindowsErik Kundiman
Plus simplifying the SHARED to STATIC stream editing by not using the global 'g' key, cause it's only 1 instance to edit. For now, BOOST_CFLAGS & BOOST_LIBS are set to refer to SLv prebuilt binary installation, along with its library suffix. try_compile doesn't seem to "compile" it, but it does configure it, so we just execute MSBuild.exe afterwards. Last time I tried, it didn't finish building or didn't build successfully, though. So what I did is manually run MSBuild.exe on ColladaDOM's solution file, and the next CMake configuration picked up the generated library, renamed to be the same as expected when using SLv prebuilt one, so that we don't have to adjust more lines for this, it has to be copied/moved anyway, might as well rename it the same. About the WIN32 definition stream editing, somehow WIN32 is not defined in daeUtils.cpp, that it would fail at deciding which commands to compile. I did try adding /DWIN32 to CXX_FLAGS but it ruined it for the Minizip header directory search. So the hack is to just forcefully define WIN32 in that file.
2025-06-03Fix vcpkg APR library names to link withErik Kundiman
2025-06-03Use LL's prebuilt Windows Boost for nowErik Kundiman
I got "definition of dllimport function not allowed" errors when using vcpkg's Boost. Someone else got this problem too: https://github.com/boostorg/serialization/issues/278 Hopefully later we can get back to using vcpkg's Boost.
2025-06-03Re-include GLEXT.cmake, but for Windows onlyErik Kundiman
There doesn't seem to be glext.h on Windows, so we'll just use the package from LL for now.
2025-05-29Merge branch '2025.04'Erik Kundiman
2025-05-27Fix mistake, don't self-build ColladaDOM on Windows for nowErik Kundiman
2025-05-27Pass configuration phase with vcpkg replacing MSYS2Erik Kundiman
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-22Merge branch 'main' into 2025.04Erik Kundiman
2025-05-14Revert "Revert to LL's OpenJPEG fork"Erik Kundiman
This reverts commit 3a36cdf6ebd9d2795bdcd14162f38df568d51796.
2025-05-13Include Expat *before* APR when configuring depsErik Kundiman
On some platforms where there's no such system library, and no prebuilt binaries for them, Expat needs to be built first before APR, because apr-util depends on Expat.
2025-05-13Lose the not really required double quotesErik Kundiman
on the CMake string match tests.