Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
results in a version of the DRTVWR-519 that matches what was presemt before it was deployed as a release viewer *plus* 3 small fixes from Maxim (See commits). This branch can now be used for additional fixes before eventually being used to release D-519 as normal
|
|
|
|
|
|
DRTVWR-519"
This reverts commit e61f485a04dc8c8ac6bcf6a24848359092884d14, reversing
changes made to 00c47d079f7e958e473ed4083a7f7691fa02dcd5.
|
|
|
|
|
|
|
|
|
|
Due to crash inside uriparser's code
|
|
|
|
|
|
|
|
|
|
|
|
|
|
llcache but @henri's suggestion that that doesn't reflect the other files in the same place and it should be llfilesystem is a good one so I changed it over
|
|
changes to remove LLVFS and LLVFSThread classes along with the associated source files. The existing llvfs folder is renamed to llcache. Also includes changes to CMake script in many places to reflect changes. Eventually, llvfile source file and class will be renamed but that is not in this change.
|
|
branch. Cloned canonical viewer into DRTVWR-519, copied over the files that changed from DRTVWR-506-simple and pushed back. Once I am satisfied everything is correct, DRTVWR-506-simple will be removed
|
|
|
|
|
|
PreferredToolArchitecture=x64 option (required for 32bit TeamCity builds) on 32 bit builds generally - removes a ton of 'unknown option, ignored' spam in the build output
|
|
# Conflicts:
# indra/cmake/DirectX.cmake
# indra/newview/llviewerparcelmedia.cpp
# indra/newview/viewer_manifest.py
|
|
|
|
to avoid TeamCity build failures due to 32-bit compiler running out of virtual
memory for precompiled headers.
|
|
library on Mac
|
|
|
|
# Conflicts:
# indra/newview/CMakeLists.txt
# indra/newview/viewer_manifest.py
|
|
|
|
and the 8.1 SDK) DirectX is included in the SDK and does not need any
special detection logic.
|
|
|
|
First, get rid of ancient cruft in the find_path() calls: on a 64-bit system,
"$ENV{PROGRAMFILES}" expands to the 64-bit 'Program Files' directory rather
than the 32-bit 'Program Files (x86)' directory, and none of the ancient cruft
would be found there anyway.
Empirically, find_path(dxdiag.h) is able to find the file using environment
variables (INCLUDE from VS variables?), so it doesn't need the specific
pathnames coded into that call.
Once we find DIRECTX_INCLUDE_DIR, don't immediately insert it into
include_directories: we've had troubles with incompatible Windows SDK versions
(compile errors in Microsoft header files!) when DIRECTX_INCLUDE_DIR preceded
the Windows SDK directory in the include path.
The DIRECTX_FIND_QUIETLY logic seemed backwards: the message(STATUS) output was
emitted only when DIRECTX_FIND_QUIETLY was false. Reverse that.
The ancient cruft in find_path(dxguid.lib) was causing it to find the wrong
(very old) DirectX library. Remove ancient cruft. But empirically, without
that, even once we've found DIRECTX_INCLUDE_DIR, CMake could not implicitly
find dxguid.lib. If the DirectX directory hierarchy were structured as
.../version/Include and .../version/Lib, a relative pathname would have been
sufficient hint. Unfortunately it's structured as .../Include/version and
.../Lib/version, so a relative pathname would have to include the specific
version. Instead, replace "/Include/" with "/Lib/". But even then, we have to
drill down to the architecture-specific subdirectory based on ADDRESS_SIZE.
|
|
|
|
# Conflicts:
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorypanel.cpp
# indra/newview/lltexturectrl.cpp
# indra/newview/skins/default/xui/de/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/es/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/fr/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/it/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/ja/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/pt/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/ru/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/tr/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/zh/floater_texture_ctrl.xml
|
|
|
|
|
|
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.
|
|
|
|
Thanks NickyD.
|
|
|
|
|
|
xcode's PATH
|
|
|
|
|