| Age | Commit message (Collapse) | Author |
|---|
|
|
|
X11 is still required too, that's why it's still added for linking.
On Darwin, SDL is disabled for now.
|
|
for now. Dictionaries should later be enabled when we have arrived at
the point where everything has run well that the next stage would be the
packaging for the distribution stage.
|
|
and at the same time escape use_prebuilt_binary commands in the file.
|
|
So far all of GTK2 dependencies flags, such as for Pango, Cairo, PNG16,
etc., seem to be implied by checking the gtk+-2.0 module alone, at least
on FreeBSD and Debian.
|
|
The module name to check with pkgconf is different, hence the special
treatment.
|
|
There are also several additional flags from running pkgconf that we
don't get from pkg_check_modules. At least 1 is needed later when
compiling llprimitive.
|
|
Since the CMakeLists.txt includes some same .cmake files as the viewer,
I think the project might as well be a part of the Linden libraries
code. And for now is put under llprimitive (might not be consistent, in
fact the opposite, with they way llplugin relates to slplugin), but I
think this way results the least change, and it still works.
The differences include:
- all files (common llphysicsextensions headers to be included by
library users and the stub implementation files) are put inside one
directory, and the CMakeLists.txt is adjusted accordingly;
- modernised CMakeLists.txt, so include_directories are now implied by
target_link_libraries;
- some file name fix;
- add_library is not explicitly set to STATIC;
|
|
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.
|
|
|
|
# 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.
|
