summaryrefslogtreecommitdiff
path: root/indra/cmake
AgeCommit message (Collapse)Author
2021-03-09This set of changes reverts the merge with master (git revert c83e740) and ↵Callum Prentice
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
2021-03-08Revert "Merge branch 'master' of https://bitbucket.org/lindenlab/viewer into ↵Brad Payne (Vir Linden)
DRTVWR-519" This reverts commit e61f485a04dc8c8ac6bcf6a24848359092884d14, reversing changes made to 00c47d079f7e958e473ed4083a7f7691fa02dcd5.
2020-10-06Remove SQLite from project and we are now not going to use it for the cacheCallum Prentice
2020-09-28Merge with tip of ReleaseCallum Prentice
2020-09-22Add SQLite third package to this viewer and pull in the most recent build (3.33)Callum Prentice
2020-09-22Merge branch 'master' v6.4.9 into DRTVWR-497Dave Houlton
2020-09-22Merge branch 'master' into DRTVWR-519Callum Prentice
2020-09-17The folder where the disk cache lives was originally renamed from llvfs to ↵Callum Prentice
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
2020-09-16First part of change to remove LLVFS from the Viewer. Consists of code ↵Callum Prentice
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.
2020-09-11Effective rename of DRTVWR-506-simple since there is no way to rename a ↵Callum Prentice
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
2020-08-24DRTVWR-497 restore parallel builds for x64 VS2017Dave Houlton
2020-08-21Small change to CMake options to only enable the ↵Callum Prentice
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
2020-08-11Merge branch 'DRTVWR-501-maint' into DRTVWR-503-maintAndrey Lihatskiy
# Conflicts: # indra/cmake/DirectX.cmake # indra/newview/llviewerparcelmedia.cpp # indra/newview/viewer_manifest.py
2020-07-22Mac buildfixAndrey Lihatskiy
2020-06-26DRTVWR-476: On Windows, request 64-bit compilerNat Goodspeed
to avoid TeamCity build failures due to 32-bit compiler running out of virtual memory for precompiled headers.
2020-06-02Merge branch 'master' into DRTVWR-503-maintAndrey Lihatskiy
# Conflicts: # indra/newview/CMakeLists.txt # indra/newview/viewer_manifest.py
2020-06-02DRTVWR-476: Merge branch 'master' of bitbucket.org:lindenlab/viewer into d476.Nat Goodspeed
2020-05-20Remove DirectX.cmake. With recent SDKs (dating back to at least VS 2013Nicky Dasmijn
and the 8.1 SDK) DirectX is included in the SDK and does not need any special detection logic.
2020-05-11DRTVWR-476: Use find_library(dxguid) rather than find_path().Nat Goodspeed
2020-05-07DRTVWR-476: Help DirectX.cmake cope with multiple SDK versions.Nat Goodspeed
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.
2020-05-06DRTVWR-476: Merge branch 'master' of lindenlab/viewer into DRTVWR-476-boost-1.72Nat Goodspeed
2020-05-05Merge branch 'DRTVWR-501-maint' into DRTVWR-503-maintAndrey Lihatskiy
# 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
2020-04-20Merged master into DRTVWR-508Andrey Kleshchev
2020-04-09DRTVWR-476: For Boost 1.72, must suffix lib names with -x{32,64}Nat Goodspeed
2020-03-25DRTVWR-476, SL-12205: Refactor MSVC redist library copying.Nat Goodspeed
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.
2020-03-25DRTVWR-476, SL-12205: Search for msvcp140.dll, not msvcr140.dllNat Goodspeed
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.
2020-03-25DRTVWR-476, SL-12205: Update to glod built with VS 2017 runtime libs.Nat Goodspeed
2020-03-25DRTVWR-476: For VS 2017, MSVC_VERSION can be any of a range.Nat Goodspeed
Thanks NickyD.
2020-03-25DRTVWR-476: We've observed a couple different values for VS 2017.Nat Goodspeed
2020-03-25DRTVWR-476: On Mac, copy libhunspell-1.3.0.dylib for test programs.Nat Goodspeed
2020-03-25Fix failure when building packages-info.txt when autobuild can't be found in ↵Brad Kittenbrink
xcode's PATH
2020-03-25[DRTVWR-476] - fix linkingAnchor
2020-03-25[DRTVWR-476] - test adding at beginiing of listAnchor
2020-03-25[DRTVWR-476] - legacy_stdio_definitions shld be the last library linkedAnchor
2020-03-25[DRTVWR-476] - add legacy_stdio_definitionsAnchor
2020-03-25[DRTVWR-476] - update openjpegAnchor
2020-03-25[DRTVWR-476] - fix openjpeg dll pathAnchor
2020-03-25SL-793: Use Boost.Fiber instead of the "dcoroutine" library.Nat Goodspeed
Longtime fans will remember that the "dcoroutine" library is a Google Summer of Code project by Giovanni P. Deretta. He originally called it "Boost.Coroutine," and we originally added it to our 3p-boost autobuild package as such. But when the official Boost.Coroutine library came along (with a very different API), and we still needed the API of the GSoC project, we renamed the unofficial one "dcoroutine" to allow coexistence. The "dcoroutine" library had an internal low-level API more or less analogous to Boost.Context. We later introduced an implementation of that internal API based on Boost.Context, a step towards eliminating the GSoC code in favor of official, supported Boost code. However, recent versions of Boost.Context no longer support the API on which we built the shim for "dcoroutine." We started down the path of reimplementing that shim using the current Boost.Context API -- then realized that it's time to bite the bullet and replace the "dcoroutine" API with the Boost.Fiber API, which we've been itching to do for literally years now. Naturally, most of the heavy lifting is in llcoros.{h,cpp} and lleventcoro.{h,cpp} -- which is good: the LLCoros layer abstracts away most of the differences between "dcoroutine" and Boost.Fiber. The one feature Boost.Fiber does not provide is the ability to forcibly terminate some other fiber. Accordingly, disable LLCoros::kill() and LLCoprocedureManager::shutdown(). The only known shutdown() call was in LLCoprocedurePool's destructor. We also took the opportunity to remove postAndSuspend2() and its associated machinery: FutureListener2, LLErrorEvent, errorException(), errorLog(), LLCoroEventPumps. All that dual-LLEventPump stuff was introduced at a time when the Responder pattern was king, and we assumed we'd want to listen on one LLEventPump with the success handler and on another with the error handler. We have never actually used that in practice. Remove associated tests, of course. There is one other semantic difference that necessitates patching a number of tests: with "dcoroutine," fulfilling a future IMMEDIATELY resumes the waiting coroutine. With Boost.Fiber, fulfilling a future merely marks the fiber as ready to resume next time the scheduler gets around to it. To observe the test side effects, we've inserted a number of llcoro::suspend() calls -- also in the main loop. For a long time we retained a single unit test exercising the raw "dcoroutine" API. Remove that. Eliminate llcoro_get_id.{h,cpp}, which provided llcoro::get_id(), which was a hack to emulate fiber-local variables. Since Boost.Fiber has an actual API for that, remove the hack. In fact, use (new alias) LLCoros::local_ptr for LLSingleton's dependency tracking in place of llcoro::get_id(). In CMake land, replace BOOST_COROUTINE_LIBRARY with BOOST_FIBER_LIBRARY. We don't actually use the Boost.Coroutine for anything (though there exist plausible use cases).
2020-03-25[DRTVWR-476] - fix msvc versionAnchor
2020-03-25DRTVWR-476: Update Copy3rdPartyLibs.cmake for VS 2017 version.Nat Goodspeed
Also, on Windows, put build output into build-vc$AUTOBUILD_VSVER-$AUTOBUILD_ADDRSIZE instead of hard-coding build-vc120-$AUTOBUILD_ADDRSIZE.
2020-03-25DRTVWR-494: Show copy-paste-friendly env vars and test command.Nat Goodspeed
Moderately often I want to copy the (long) integration test program path from build output and rerun the test program by hand. But typically we need environment variables set as well so it can find its dynamic libraries. This has resulted in my copying parts of several lines of build output, then pasting to a command prompt, then hand-tweaking the pasted text so it makes sense as a command. Streamline run_build_test.py output so less hand-tweaking is needed.
2020-02-21SL-12708 (Windows) Eliminate DirectX SDK June 2010 Install Requirementmaxim_productengine
2020-02-14SL-12707 Build Fails Without FMODAndrey Kleshchev
Also adds correct working directory to RelWithDebInfoOS and enables OpenAl on OS builds for windows
2020-02-04SL-12654 Remove support for building with fmod exAndrey Kleshchev
2020-02-04SL-11445 Couple small fixesAndrey Kleshchev
2020-01-31Merged in SL-11445 Upgrade Fmodex to Fmod StudioAndrey Kleshchev
2019-12-16Merge viewer-release 6.3.6 into viewwer-eep repoDave Houlton
2019-10-29merge 6.3.4-releaseDave Houlton
2019-10-29Merged in lindenlab/viewer-releaseAndreyL ProductEngine
2019-10-16mergeBrad Payne (Vir Linden)