| Age | Commit message (Collapse) | Author |
|
Add Windows x64 & macOS actions
|
|
|
|
|
|
The CEF/Dullahan and libVLC version-reporting blocks were guarded with
'#if !_M_ARM64'. _M_ARM64 is an MSVC-only predefined macro: defined only by
MSVC when targeting ARM64, never by GCC or Clang. The intent (per the
'// !LL_LINUX' comment) was to skip these blocks where the media version
headers are unavailable, but the macro only ever excludes MSVC-on-ARM64. On
Clang/macOS _M_ARM64 is undefined even on Apple Silicon, so the blocks
compiled and failed with:
fatal error: 'cef/dullahan_version.h' file not found
whenever those headers were not on the include path (a build with
ENABLE_MEDIA_PLUGINS off, or any non-MSVC platform lacking the headers).
Gate the includes and the two version-string blocks on the LL_CEF / LL_VLC
compile definitions emitted by newview/CMakeLists.txt, which track the
actual build configuration. The combined include/usage is split so a
platform that provides one library but not the other is handled correctly.
|
|
The viewer reports the bundled libVLC and CEF/Dullahan versions in the
Help->About info. Whether those version headers are available is a build
configuration fact (ENABLE_MEDIA_PLUGINS, and for CEF the DARWIN/LINUX
condition), not a CPU/compiler property. Emit LL_VLC and LL_CEF compile
definitions that mirror the existing media-plugin link availability so the
source can gate the version-reporting code on the build configuration.
No behavior change on platforms that already link these libraries.
|
|
This reverts commit 16d3d725998f1189083c429a1cbb2cc3fb15b7da.
|
|
teleport screen
|
|
|
|
|
|
This reverts commit 379e5442803edda3d1f2e8120abb5c8f7a85f288.
|
|
|
|
|
|
|
|
|
|
|
|
Arch's system CEF version is 147 so we choose Dullahan version 1.30.
|
|
Fedora's system CEF version is 146.0.11 so we choose the Dullahan
version that uses the next closest CEF version (146.0.12 and not
146.0.10), which is Dullahan 1.29 and not 1.28.
System libcef_dll is somehow distributed only in source form
(on Arch too), so in order to be able to link to it, we have to
compile it first, but its CMakeLists.txt is a sub one, incomplete,
so we use the solution of adding an empty macro:
https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=17732
System CEF's library encapsulating folder that contains libcef.so,
hence needs to be add to runtime path.
|
|
This includes files of WebRTC, Discord, VLC & CEF and their media
plugins & resources.
This is so they won't clash just in case some other packages install
files with the same names in system library directories.
Furthermore, this seems to prevent Dullahan/CEF from breaking in
general.
The path to this encapsulating folder needs to be added as a runtime
path to especially dullahan_host & libmedia_plugin_cef.so so they can
find libcef.so etc, also for the viewer to find libllwebrtc.so &
libdiscord_partner_sdk.so. And that's why `patchelf` needs to be made
sure it's installed.
|
|
|
|
tinting
- Quick Preferences floater with hover height and bandwidth sliders
- Mouselook right-click zoom with scroll wheel adjustment
- Group-based nameplate color tinting via group profile
|
|
I believe it was meant to grey out "Automatic" on "Mouse Warp".
Also, FreeBSD is added to this condition.
|
|
|
|
|
|
See commit 21ef63545ca07ef625edb742b2b3d1473bf33f13
|
|
|
|
Apart from FreeALUT for all distros now, not needing FMOD any more,
Ubuntu gets an extra dependency, which is (system) OpenJPEG, like the rest.
|
|
Also, its private headers haven't been used, for other platforms
either, so no need to use the encapsulating folder any more.
The last line in .cmake is kept though, otherwise somehow on Gentoo
llrender wouldn't have packages/include as its target include
directories for finding glh's header directories.
None of the Linux distros bundle OpenJPEG any more now.
|
|
and use PipeWire instead of PulseAudio for controlling web media
volume by default.
|
|
This reverts commit 934b2de85e33fd2d4a7bf9abe12dcdeb743ff418.
|
|
This reverts commit bf0ab355d501017669f0efeb1ca269a1dccc21bc.
|
|
|
|
On default Debian/Ubuntu GNOME-based distributions, there's already
pipewire-pulse, which would prevent WebRTC from crashing too. But in the
viewer current state, using that, would break CEF. And the difference in
our Debian arm64 build is, that it uses OpenAL and not FMOD.
So pulseaudio is used for now (it would force remove pipewire's daemon
if pipewire's is already installed, like on GNOME-based distros), until
we can have pipewire-pulse, OpenAL, CEF and WebRTC, all getting along.
|
|
This reverts commit 8d34bb549736c341e84123760901bc981c46b184.
|
|
This reverts commit e2bbc96a057eaacf8bfbc6614c156634a7697ee0.
|
|
This reverts commit 00a44adfbeac89ed646b517446cbade82da531f8.
|
|
This reverts commit 038ac8ea747b680b73bbce6a5a426abcd8132e22.
|
|
|
|
The previous would make none compile WebRTC code in llvoiceclient.cpp.
|
|
|
|
Similar crash as on Debian arm64. I thought it was because I hadn't
had sound working yet on my installation, but after I got sound working,
it still crashed with WebRTC on.
See commit 8d34bb549736c341e84123760901bc981c46b184
|
|
platforms that can't have WebRTC support yet or have some problem
with WebRTC (crashed by it).
|
|
From SDL2 to sdl2-compat and from openjpeg2 to openjpeg.
|
|
|
|
|
|
use libboost 91
|
|
|
|
The error was:
C:\Users\erik\Documents\vcpkg\installed\arm64-windows\include\boost\json\detail\value_from.hpp(152,9): error C2338: static assertion failed: 'No suitable tag_invoke overload found for the typ
e' [C:\Users\erik\Documents\Megapahit\viewer\build-mingw64_nt-10.0-26200-arm64\newview\Megapahit.vcxproj]
(compiling source file '../../indra/newview/llviewerdisplay.cpp')
C:\Users\erik\Documents\vcpkg\installed\arm64-windows\include\boost\json\detail\value_from.hpp(152,9):
the template instantiation context (the oldest one first) is
C:\Users\erik\Documents\Megapahit\viewer\indra\newview\llviewerdisplay.cpp(1112,48):
see reference to function template instantiation 'boost::json::value_ref::value_ref<T>(const T &,void *) noexcept' being compiled
with
[
T=boost::json::object_kind_t
]
C:\Users\erik\Documents\vcpkg\installed\arm64-windows\include\boost\json\value_ref.hpp(230,1):
see reference to function template instantiation 'boost::json::value boost::json::value_ref::from_const<T>(const void *,boost::json::storage_ptr)' being compiled
with
[
T=boost::json::object_kind_t
]
C:\Users\erik\Documents\vcpkg\installed\arm64-windows\include\boost\json\impl\value_ref.hpp(29,12):
see reference to function template instantiation 'boost::json::value boost::json::value_from<const T&>(const boost::json::object_kind_t&,boost::json::storage_ptr)' being compiled
with
[
T=boost::json::object_kind_t
]
C:\Users\erik\Documents\vcpkg\installed\arm64-windows\include\boost\json\value_from.hpp(146,11):
see reference to function template instantiation 'boost::json::value boost::json::value_from<const T&,boost::json::detail::no_context>(const boost::json::object_kind_t&,const Contex
t &,boost::json::storage_ptr)' being compiled
with
[
T=boost::json::object_kind_t,
Context=boost::json::detail::no_context
]
C:\Users\erik\Documents\vcpkg\installed\arm64-windows\include\boost\json\value_from.hpp(125,5):
see reference to function template instantiation 'void boost::json::value_from<const T&,Context>(const boost::json::object_kind_t&,const Context &,boost::json::value &)' being compi
led
with
[
T=boost::json::object_kind_t,
Context=boost::json::detail::no_context
]
C:\Users\erik\Documents\vcpkg\installed\arm64-windows\include\boost\json\value_from.hpp(97,13):
see reference to function template instantiation 'void boost::json::detail::value_from_impl<const T&,Context>(boost::json::detail::no_conversion_tag,boost::json::value &,const boost
::json::object_kind_t&,const Ctx &)' being compiled
with
[
T=boost::json::object_kind_t,
Context=boost::json::detail::no_context,
Ctx=boost::json::detail::no_context
]
|
|
|
|
|
|
|