| Age | Commit message (Collapse) | Author |
|---|
|
cause it's available now on trixie.
|
|
|
|
and don't rebuild NDOF on non x86-64 Linux when it's already installed.
|
|
|
|
|
|
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.
|
|
almost forgot!
|
|
add cmake and patch to tumbleweed build instructions
|
|
https://stackoverflow.com/questions/60588765/how-to-get-cpu-brand-information-in-arm64
|
|
|
|
Move semicolons for improved readability. (Sorry!)
|
|
Put ".tar.gz" and "/Downloads" in code blocks for increased visibility.
|
|
Update build instructions for distributions that require fmod in order for CEF to work, optionally include instructions for building with openal anyway.
|
|
working CEF"
(I messed up the hyperlinks lol)
|
|
Add notes about where to get fmodstudio, and optionally how to build with openal instead.
|
|
|
|
Also add cpuinfo to build preparation instruction.
|
|
|
|
There's a different section for Windows arm64, cause there are
different patterns in the commands that are too difficult to generalise.
BuildTools is used instead of the full Visual Studio IDE,
and BuildTools is installed in Program Files (x86)
on both Windows x64 and arm64.
The CMake used is the one automatically installed by vcpkg, and it
can find the compilers when the toolchain file setting is set to
the file provided by vcpkg.
This way we don't have to install VS CMake component that depends
on x64/x86 build tools, which we don't need for Windows arm64.
The pkg-config used is the other one downloaded, as the path to it
is common on both Windows arm64 and x64.
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).
|
|
Put the necessary files into place.
But, none of them is working just yet.
|
|
Turns out the CMAKE_BUILD_TYPE setting is necessary, otherwise it would
be built in RelWithDebInfo configuration.
Reorganise the contributors generation and general CPack settings in
indra/newview/CMakeLists.txt.
Running sed when cross-comping for Linux, on FreeBSD, doesn't need to
use Linux's sed, so no need for ${CMAKE_SYSROOT}/usr/bin prefix, this
way that section can be reused for Windows.
I still couldn't get CPack to make NSIS not use the version numbers as
part of the default installation destination.
Using TARGETS for installing llwebrtc would cause the .lib to be
installed too, which isn't necessary, that's why we use PROGRAMS.
contributors.txt still gets generated wrongly.
The executable icon is still SL's test icon.
ColladaDOM's failure to link to Boost throw_exception, from its use of
Boost Regex, is not fixed yet. I got to this stage by temporarily
removing the offending lines in daeURI.cpp (which are the lines where
Boost Regex is used).
|
|
This reverts commit 2bf9d234aac30ed4a85282730da0ffc83acf9adf.
|
|
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.
|
|
otherwise we'd have to deal with every warning.
Instruction for building from the command line too.
Add MSBuild binary directory to PATH, and MSBuild needs its .exe
extension typed too for it to be found, unlike other commands such as
cmake, vcpkg, pkg-config, and so on.
By default, MSBuild builds using the RelWithDebInfo configuration, hence
the -p:Configuration parameter to have Release instead.
I guess that's why CMake would consider CMAKE_BUILD_TYPE as not being
used by the project.
|
|
Update libboost package names.
|
|
and remove the necessity of using sudo to su on FreeBSD,
just like on Gentoo.
|
|
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.
|
|
Even though the windlight file names containing %20 & %21 isn't liked by
either CPack or FBSD packaging problem will eventually have to be
solved, the hack steps are small that they should just be documented,
in case (more) others would like to build the FBSD package.
Use custom PYTHON environment setting instead of relying on creating
links named python and/or python 3 to the system Python executable.
Reorder build requirements, add missing dependencies that can be set to
automatically installed. The absences of some were leftovers from
dependency on system ColladaDOM and GTK2 (or my failure to add some
package names to the CPack dependencies, caused by the gtk2 vs. gtk20,
apr vs. apr1, sdl2 vs. sdl20, etc. FBSD package/port naming confusion).
|
|
This reverts commit 3a36cdf6ebd9d2795bdcd14162f38df568d51796.
|
|
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.
|
|
Our Arch builds have been having NDOF enabled all this time.
|
|
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.
|
|
Turns out it hasn't been needed, might be leftover from system Collada
DOM, and LL has their own URI parser.
|
|
It's installation is not implied by any other package for the project,
at this moment.
|
|
|
|
by the platform/OS/distro name.
Add -a to emerge since it's very likely the user hasn't set some
necessary USE flags on before they try to install the viewer.
Decapitalise openSUSE's initial letter.
|
|
Gentoo uses lib64, just like Fedora, and has libexec too.
The necessary step to install dependencies is part of the ebuild script
now (tracked in another repo, ebuild.git).
One thing I forgot to mention on the commit in that ebuild repo is,
unzip.h is provided on Gentoo only by minizip, and not minizip-ng cause
somehow the (minizip) "compat" USE flag couldn't be turned on somehow,
and there was no "minizip" (without -ng) package on Gentoo, but it was
achievable by setting the "minizip" USE flag on the zlib (again, without
-ng) package.
The queue header inclusion is needed cause its absence would cause the
compiling to fail on Portage (though it compiled when building the
viewer manually without Portage).
Also, using the prebuilt Meshoptimizer caused some linking errors when
using Portage (though, again, it linked when building the viewer
manually without Portage), hence Meshoptimizer is built from source as
part of the CMake configuration on Gentoo, differing from fellow Linux
distros.
Now Collada DOM, firstly the unpack destination directory is moved to
inside the build directory now, to make it uniform with other 3rd-party
files, just for less confusion. Secondly, since the patching that takes
effect is the one done by Portage, it would kill the process when there
are offending failed patchings (ones that generate .rej, reject files),
and they are the vcxproj patchings which aren't used anyway. Thirdly,
the hash checking on the downloaded file, that would fail anyway since
Portage doesn't allow any downloading that isn't part of the ebuild,
unfortunately has to be skipped so the emerge process wouldn't be killed
just because of it. Ebuild has its own sum checking (though this means
this particular file is not checked on other platforms, but other files
aren't checked either anyway yet).
Last but not least, the XDG Application category is removed because it's
considered deprecated by Portage, though not fatal, but the viewer is
already shown well in the Internet (Network) submenu anyway on unix
desktops.
|
|
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.
|
|
SLD2-devel no longer exists in tumbleweed repositories, replace with libSDL2_gfx-1_0-0, libSDL2_gfx-devel, & sdl2-compat-devel
|
|
since we started using more recent patch versions of LL's Collada DOM
fork.
|
|
The Collada DOM upstream patch version is one that doesn't depend on PCRE
anymore anyway.
|
|
and therefore LL's Collada DOM can be upgraded to something newer
than r4, and therefore PCRE can be no longer depended on.
Have to set the C++ standard so it doesn't use anything old, but
also it wasn't ready for something as new as C++20 yet, that's why
it's explicitly set to C++17.
Have to set the architecture too when you're cross-compiling,
it would use the native architecture.
|
|
update & include new libboost packages
|
|
Upstream is shifting towards C++20.
|
|
instead of talking about SL & showing its trademarks first.
|
|
for now. Same reason, using FMOD is the method that doesn't break CEF on
Arch.
|
|
|
|
|
|
|
|
|
