| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
though implicitly pulled by curl which is pulled by cmake & git.
|
|
|
|
which fixes the problem of freezing/crashing or disappearing of the
viewer, at least on default GNOME-based Debian.
|
|
|
|
for FreeBSD as it's the one that would pull dependencies automatically
More for users that are trying to figure out the command for installing
the binary package, and they read this README (which is actually for
builders, who could still use pkg add).
|
|
|
|
The mirror that displays Markdown files with hyperlinks and all,
is GH's anyway.
|
|
|
|
Now that MacPorts' newest Boost version is 1.88.
|
|
Update libboost packages to ver 89
|
|
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.
|
|
This reverts commit cbf64f875831992386dadc5a094b9739b678b764.
|
|
Turns out it's not necessarily pulled by some other dependencies
on a fresh Arch installation.
|
|
previously unintentionally left out from commit 829e4
|
|
Turns out the one used is
installed/<arch>-windows/tools/pkgconf/pkgconf.exe which is installed by
some package...
No special PKG_CONFIG_LIBDIR/PATH needed either.
|
|
and it turns it's installed automatically for building some of our
dependencies, and *not* by the "pkgconf" package.
|
|
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.
|
