| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Shorter.
|
|
Media plugins enabling not yet.
OpenXR is disabled for now (it hasn't been used anyway).
perl-FindBin is needed to be able to build OpenSSL on Fedora aarch64.
Setting the C standard to 90 when building cURL is needed, otherwise
it would fail at configure time with a misleading error of not finding
link/run time requirements for dependencies (such as nghttp2 and zlib),
at least on Fedora (and macOS too back then, I remember).
GCC treated SSE2NEON warnings as errors on so many files,
so -Wno-cpp is added globally.
The same Linux CPU frequency calculation needs to be out of the x86 scope,
otherwise the viewer would complain about not meeting the requirements
at launch time.
|
|
cause somehow WebRTC voice didn't work with LL's (Vivox still worked)..
Also with LL's, so many devices detected;
while with CM's, only built-in audio input device detected.
|
|
I've tried using FMOD instead, but CEF didn't work either.
At first I used crow-misia's WebRTC build but it would cause a
segmentation fault, but LL's build seems to break CEF.
Gotta find a way so CM's build doesn't crash the viewer.
PKGBUILD should be moved to indra/newview as an .in to be configured
by CMake for dynamic version numbers, and adjust the instruction
too to run makepkg -R from the folder where the generated PKGBUILD
will be.
|
|
Also simplify CMake-based dependency projects, the parameters that
have been set for the viewer seem to have been implied all this time
for the subprojects.
|
|
|
|
Now that it's only Debian and macOS x86-64 that are left safe to use
LL's WebRTC build, the logic is reversed.
|
|
Thanks to the Linux x86-64 WebRTC binary from Zenichi Amano (crow-misia).
https://megapahit.com/show_bug.cgi?id=64
Haven't been tested on openSUSE, but it should work.
|
|
on macOS arm64, the header directory.
|
|
|
|
It breaks CEF on these platforms.
|
|
for macOS arm64.
|
|
|
|
|
|
Still triggered by upstream autobuild.xml even though there is
actually no need to update on macOS arm64's side.
|
|
|
|
2024.06-atlasaurus
|
|
for when autobuild's not installed.
|
|
|
|
|
|
|
|
|
|
|
|
Also, start/stop recording depending on whether WebRTC has negotiated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
