| Age | Commit message (Collapse) | Author |
|---|
|
|
|
gigantic CMake patch. Sadly, my macOS box updated to Xcode14.3 overnight and that caused many warnings/errors with variables being initialized and then used but not in a way that affected anything.. Building on Xcode 14.3 also requires that MACOSX_DEPLOYMENT_TARGET be set to > 10.13. Waiting on a decision about that but checking this in in the meantime. Builds on macOS with appropriate build variables set for MACOSX_DEPLOYMENT_TARGET = 10.14 but not really expecting this to build in TC because (REDACTED). Windows version probably hopelessly broken - switching to that now.
|
|
# 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:
# 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
|
|
the right place in Windows builds
|
|
|
|
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
|
|
|
|
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.
|
|
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
|
|
|
|
|
|
configuration specific, rather than staging files to Release and
RelWithdebInfo all the time
|
|
on Linux again.
|
|
case insesitive fielsystem, this is why it was not issues there
- Remove input files that are obsolete.
|
|
- Targets now define the appropriate c++ defines, no more hand magic needed for llstartup.cpp
- Switch cmakeflage to USE_xxx rather than xxx as it was before. I personally find the USE_X notion more intuitive and it follows how KDU is used.
- To be backward compatible OPENAL/FMODSTUDIO flag will be mapped to USE_OPENAL/USE_FMODSTUDIO
|
|
what's with that, maybe it gets set by LLs teamcity builds?
|
|
(seems to be the case for Windows)
|
|
|
|
|
|
|
|
|
|
|
|
Moving a copy of OpenSSL 1.1.1 to D543 from D520 to have less conflicts with zlib-ng integration later
|
|
# Conflicts:
# autobuild.xml
# indra/CMakeLists.txt
# indra/newview/CMakeLists.txt
# indra/newview/llappviewerwin32.h
# indra/win_crash_logger/llcrashloggerwindows.cpp
Cherry picked from DRTVWR-520
|
|
# Conflicts:
# autobuild.xml
# build.sh
# indra/CMakeLists.txt
# indra/newview/CMakeLists.txt
# indra/newview/llappviewermacosx.cpp
# indra/newview/llappviewerwin32.h
# indra/newview/viewer_manifest.py
# indra/win_crash_logger/llcrashloggerwindows.cpp
|
|
|
|
Bring in Oz's tweaks to the way BugSplat is engaged and tested, plus a few
other miscellaneous goodies.
|
|
|
|
|
|
|
|
Due to crash inside uriparser's code
|
|
|
|
# Conflicts:
# indra/cmake/DirectX.cmake
# indra/newview/llviewerparcelmedia.cpp
# indra/newview/viewer_manifest.py
|
|
|
|
|
|
# Conflicts:
# indra/newview/CMakeLists.txt
# indra/newview/viewer_manifest.py
|
|
|
|
Specify all of msvcp$VER.dll, msvcr$VER.dll and vcruntime$VER.dll -- but check
each of them individually, because any given VS release has only a subset of
those. Add messaging to clarify what we're doing.
Introduce to_staging_dirs CMake macro to cut down on redundant boilerplate:
the idiom in which we use copy_if_different twice, once to the Release staging
directory and once to the RelWithDebInfo staging directory, each time
appending the target pathnames to third_party_targets. Replace that idiom with
calls to to_staging_dirs.
|
|
Evidently, with VS 2017, what would have been msvcr140.dll has become
vcruntime140.dll instead. msvcr140.dll is no longer a good sample DLL for
which to search.
|
|
|
