| Age | Commit message (Collapse) | Author |
|---|
|
https://stackoverflow.com/questions/60588765/how-to-get-cpu-brand-information-in-arm64
|
|
This reverts commit 32871ee579bfbd4828f7888550897f619fdfd9d7.
|
|
Basically just add what the author added to the file.
https://github.com/JochenKalmbach/StackWalker/commit/2a96079ba54a905d29afb3834182cbf06eff9132#diff-0d2beffe54d2ad0b9c31814fc48e5ef5841ba542fe545bba8b8971c767c89911
|
|
Also add cpuinfo to build preparation instruction.
|
|
This commit is for getting rid of the compile error for now,
we don't know yet if this will work correctly or not.
|
|
Just copying from this:
https://forum.juce.com/t/windows-arm64-support/47572/6
This commit is for getting rid of the compile error for now,
we don't know yet if this will work correctly or not.
|
|
'std::char_traits<unsigned short>' on FreeBSD.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282329
|
|
I felt like they slowed down the flow.
https://developercommunity.visualstudio.com/t/warnings-in-a-windows-sdk-header-when-compiling-wi/897227
|
|
Parsing failed on macOS' CMake (could be MacPorts, could be the version)
for some reason.
|
|
|
|
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.
|
|
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.
|
|
and get rid of the error:
'apr_sockaddr_t::sin6' uses undefined struct 'sockaddr_in6'
|
|
This reverts commit 71d777ea126e7f02cb46c11bdb606094ca06f75c.
|
|
This reverts commit 5ed8df22cd59680a685c4ada7daa5555bf59d4fe.
|
|
|
|
|
|
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.
|
|
|
|
to make it more flexible the next time a value in the if's parentheses
gets changed again, and also to reduce duplicate pattern matches when
grepping those CMake files with certain keywords.
|
|
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.
|
|
|
|
with the effect of choosing zlib over zlib-ng in any condition, which
has been the case so far. But this opens the way to relying on some
other condition, such as which platform, for deciding whether we can
use zlib-ng or not, instead of zlib. So we can freely use, for example
LL's prebuilt, zlib-ng while still using system libraries for others.
|
|
The only condition where Expat headers would be encapsulated is when
using LL's Autobuild-based prebuilt libraries, and we're never using
any of LL's prebuilt binary for Expat on desktop, since Expat is
practically available on any supported desktop platform.
The system Expat headers are never encapsulated in any of those
platforms.
This is the beginning of not relying on the LL_USESYSTEMLIBS macro
any more (eventually not relying on the custom USESYSTEMLIBS CMake
setting either).
Keeping the build system still flexible to have the option to use
LL's prebuilt libraries *fully* (we still use some of them in cases
where the platform may not have the related system library or for
convenience, so the term USESYSTEMLIBS may not always be consistent),
is getting harder to maintain.
The way it's done is using #if 1, in order to minimise difference
from upstream.
|
|
|
|
Simpler.
|
|
The two conditions might not be exclusive for some platforms
(in another branch).
|
|
|
|
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.
|
|
|
|
* Make eligible functions constexpr
* Use constants for vector indices where applicable
* Reformat to match actual coding conventions
|
|
Merge 2025.03 release into develop.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
We need those to know about problems.
|
|
|
|
|
|
It was reporting shutdown as crashes to bugsplat
|
|
This changeset adds a timestamp in the format of "YYYY-MM-DD_HHSS" to
snapshot filenames. This is useful for understanding when a snapshot was
taken, chronologically ordering files, and is less confusing than the
current method of adding a number to the snapshot name, as it does not
result in interleaving of old and new snapshots inside a directory.
|
|
|
|
|
|
2024.12-ForeverFPS
|
|
Jumped the gun a bit, since reportCrashToBugsplat is OS specific,
restore rethrow for other systems.
|
|
Update develop with ForeverFPS
|
