| Age | Commit message (Collapse) | Author |
|---|
|
The Meshoptimizer CMake files don't seem to be working right. On more
than one platform, they always conclude the package as not found.
Nevertheless, the library is typically installed in standard paths, that
no special paths need to be included for Meshoptimizer to be found.
Except on macOS (so far), as existing package managers don't have that
package yet, hence the /usr/local/include addition. It's a safe path to
include anyway on other un*x platforms.
|
|
The module name to check with pkgconf is different, hence the special
treatment.
|
|
|
|
for the same reason as GLH, but since the headers are expected to be
installed in the same directory as GLH (and GLEXT.cmake includes
GLH.cmake), we can skip any additional directory to look the headers for.
|
|
No package manager that I know of provide such package. So this one is
expected to be installed in /usr/local/include.
|
|
Some distros already include OpenSSL as part of the distribution,
that OpenSSL may not be provided with its .pc files, even though they're
available upstream.
|
|
The xmlrpc-epi package has no .pc or .cmake files. On some platforms,
the header and the library directories don't have special paths. On
GNU/Linux, at least on Debian, the headers are encapsulated in the
packages's own directory. On macOS, both MacPorts & Homebrew don't have
the package. On the other hand, Fink, that has the package, still
doesn't support recent versions of macOS as of this writing. So it's
very likely that on macOS, xmlrpc-epi is installed in /usr/local.
|
|
Calls to zlib-ng in the viewer code aren't prefixed. And in order to
build, the zlib-ng package needs to be configured with the ZLIB_COMPAT
option on. Some package managers may not have provided the option on, or
to turn that on, yet.
|
|
|
|
The necessary linker flags to link the required Boost libraries are
somehow not obtained from find_package. Passing boost_context,
boost_fiber, or so on to find_package didn't help getting the linker
flags either. Hence the manual listing of the Boost libraries to link.
|
|
On some platforms such as FreeBSD or MacPorts,
pkg-config --libs apr-util-1
already includes -lapr-1. But on APT, the apr-1 module needs to be
checked too.
|
|
|
|
It was set to the same value as PKG_CONFIG_MULTI_LOCAL_GUESS before.
That's why it couldn't find any package installed by the package manager
on a GNU/Linux distro.
|
|
Its use_system_binary implementation first tries to use pkg-config to
generate the necessary flags. But if it doesn't find the package, then
it will try to use find_package.
The USESYSTEMLIBS is also brought back again though only in 1 place, and
the name because it's the one still on the wiki page (the building the
viewer with Autobuild one), so the CMake variable is not totally new.
|
|
following promotion of DRTVWR-580
|
|
|
|
improvements can lead to perceived inventory loss due to cache corruption"
This reverts commit cf692c40b0b9f8d0d04cd10a02a84e3f697a2e99.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/llcharacter/llkeyframemotion.cpp
# indra/newview/llfilepicker.cpp
|
|
following promotion of DRTVWR-577
|
|
|
|
|
|
BUG-233797/233798 - fix blackout when u/w fog_density < 0
|
|
|
|
|
|
Newer C++ compilers have different semantics around LLSDArray's special copy
constructor, which was essential to proper LLSD nesting. In short, we can no
longer trust LLSDArray to behave correctly. Now that we have variadic
functions, get rid of LLSDArray and replace every reference with llsd::array().
|
|
|
|
Fix typos in floater_scene_load_stats.xml and llviewerstats.cpp
|
|
It seems newer compilers have a different interpretation of exactly when to
engage LLSDArray's copy constructor. In particular, this assignment:
some_LLSD_map[key] = LLSDArray(...)(...)...;
used to convert the LLSDArray object directly to LLSD; now it first calls the
custom copy constructor, which embeds the intended array within an outer array
before assigning it into the containing map.
The newer llsd::array() function avoids that problem because what it returns
is already an LLSD object.
Taking inventory of LLSDArray assignments of that form turned up a number of
workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is
both simpler and more readable.
Tip of the hat to Chorazinallen for surfacing this issue!
(cherry picked from commit bb718155bddfbe7007029a0c9e69a4a98615f14d)
|
|
|
|
|
|
Reducing the packet loss...
|
|
|
|
|
