| Age | Commit message (Collapse) | Author |
|---|
|
|
|
# Conflicts:
# indra/cmake/CMakeLists.txt
# indra/newview/skins/default/xui/es/floater_tools.xml
|
|
# Conflicts:
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
# Conflicts:
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/newview/llfilepicker.h
# indra/newview/llfilepicker_mac.h
# indra/newview/llfilepicker_mac.mm
|
|
# Conflicts:
# doc/contributions.txt
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
speed matters. (#64)
This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.
Here is the comment I added in indra/llcommon/hbxx.h:
// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.
|
|
|
|
|
|
|
|
|
|
Or rather, attempting to implicitly sign. On TeamCity we must explicitly sign
using viewer_manifest.py. On a developer system, without these changes, Xcode
produces many errors of the form:
error: An empty identity is not valid when signing a binary for the product
type 'Command-line Tool'. (in target 'INTEGRATION_TEST_lldir' from project
'SecondLife')
and refuses to compile anything at all.
Thanks to Rye Mutt and NickyD. Also thanks Geir Nøklebye for additional
settings to help tame Xcode 14.1 warnings.
|
|
This reverts commit 31917709d9f4d9d4742910ae7990009a1580b150.
|
|
|
|
|
|
enable partial bitstreams
Openjpeg was modified: "p_max_len -= l_nb_bytes_read;" was causing an overflow.
I'm not sure if I did something incorectly in opj_skip/opj_seek viewer side, but seems like openjpeg should have been checking remaining space in p_max_len either way.
P.S. Many thanks to Chafey and Neopallium for implementing openjpeg's partial bitstream support
|
|
Implied 'branch' is now two different version-control systems behind
|
|
|
|
|
|
|
|
|
|
|
|
Part of his change was omly taking Release builds into account, the other
part from me made the same mistake.
Use a generator expression with a custom command to get the symlink the way
we want.
|
|
|
|
The include was preveiously declared for all platforms, but the Mac
package does not even ship this include directory. With the new way
cmake works this will lead to an error (which is good, so we don't
end with bogus include dirs).
|
|
|
|
|
|
|
|
DRTVWR-568_cmake
|
|
Converting on DRTVWR-568 as the project branch going forward.
|
|
|
|
into autobuild.xml for VS 2022 and update cmake script to copy the MSVC runtime (proper fix coming
|
|
|
|
|
|
Always search for python3[.exe] instead of plain 'python'. macOS Monterey no
longer bundles Python 2 at all.
Explicitly make PYTHON_EXECUTABLE a cached value so if the user edits it in
CMakeCache.txt, it won't be overwritten by indra/cmake/Python.cmake.
Do NOT set DYLD_LIBRARY_PATH for test executables! That has Bad Effects, as
discussed in https://stackoverflow.com/q/73418423/5533635. Instead, create
symlinks from build-mumble/sharedlibs/Resources -> Release/Resources and from
build-mumble/test/Resources -> ../sharedlibs/Release/Resources. For test
executables in sharedlibs/RelWithDebInfo and test/RelWithDebInfo, this
supports our dylibs' baked-in load path @executable_path/../Resources. That
load path assumes running in a standard app bundle (which the viewer in fact
does), but we've been avoiding creating an app bundle for every test program.
These symlinks allow us to continue doing that while avoiding
DYLD_LIBRARY_PATH.
Add indra/llcommon/apply.h. The LL::apply() function and its wrapper macro
VAPPLY were very useful in diagnosing the problem.
Tweak llleap_test.cpp. This source was modified extensively for diagnostic
purposes; these are the small improvements that remain.
|
|
allow us to reuse the macro for more than just conan.
|
|
|
|
|
|
DRTVWR-543-maint_cmake
|
|
# Conflicts:
# autobuild.xml
# indra/cmake/LLCommon.cmake
# indra/llcommon/CMakeLists.txt
# indra/llrender/llgl.cpp
# indra/newview/llappviewer.cpp
# indra/newview/llface.cpp
# indra/newview/llflexibleobject.cpp
# indra/newview/llvovolume.cpp
|
|
|
|
|
|
- Simplify detection by using regex
- OSX is always 64 bit
|
|
- ENV{LL_BUILD} takes precedence
- if ENV{LL_BUILD} is not set but LL_BUILD-ENV is, set ENV{LL_BUILD} to
the cached version
- error if none of the two is set
Caching the variable and reusing it lets cmake run when not called by
autobuild itself. This happens when xcode or visual studio detect it
needs to be re rerun and call it for the "cmake" target. Not having
LL_BUILD then makes those targets fail.
|
|
|
|
|
|
# Conflicts:
# indra/newview/llappviewer.h
|
|
|
|
linking directory.
|
|
configuration specific, rather than staging files to Release and
RelWithdebInfo all the time
|
|
sets the property on those.
|
