summaryrefslogtreecommitdiff
path: root/indra/cmake/LLCommon.cmake
AgeCommit message (Collapse)Author
2023-03-30CMake and tests fixups after merge with main for DRTVWR-559Brad Linden
2023-03-29Merge remote-tracking branch 'origin/main' into DRTVWR-559Brad Linden
2023-02-10Upgraded tracy package and enabled for mac with USE_TRACY for work on mac ↵Brad Linden
perfomance SL-18563 ``` autobuild installables edit "tracy" url="https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/110561/960415/tracy-v0.7.8.578230-darwin64-578230.tar.bz2" hash="70f31fa71ecb52bd092da52e27c3ff8c" autobuild installables edit "tracy" url="https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/110562/960424/tracy-v0.7.8.578230-windows-578230.tar.bz2" hash="1dc33422939adf015db85e96c5a8276e" autobuild installables edit "tracy" url="https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/110563/960429/tracy-v0.7.8.578230-windows64-578230.tar.bz2" hash="fcc6ecece2ecb65aa36500dfa9461fb3" ```
2023-01-31SL-19110 Fast hashing classes for use in place of the slow LLMD5, where ↵Henri Beauchamp
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.
2022-09-17SL-17238 Fix coding policy build issuesAndrey Kleshchev
2022-06-05Merge remote-tracking branch 'origin/DRTVWR-543-maint_cmake' into ↵Nicky
DRTVWR-543-maint_cmake
2022-05-27Merge branch 'master' into DRTVWR-543-maintAndrey Lihatskiy
# 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
2022-04-06Move CMake files to modernized cmake syntax, step 1.Nicky
Change projects to cmake targetsto get rid of havig to hardcore include directories and link libraries in consumer projects.
2021-09-08SL-14541 Replace zlib with zlib-ngAndrey Kleshchev
2021-09-03SL-15709: Windows: Include Tracy source directly; don't use a libraryPtolemy
2021-08-31SL-15709: Fix LLCommon not setting Tracy include directory and not linking ↵Ptolemy
to tracy.lib
2021-07-28SL-15709: Add Tracy support to viewerPtolemy
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-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).
2016-05-19Automated merge with tip of viewer-release to pick up 4.0.5callum_linden
2016-04-21DRTVWR-418 remove vestiges of TCMALLOC and GooglePerfTools from the viewercallum_linden
2016-04-04merge with 4.0.3-releaseOz Linden
2015-12-18Reorder the rt library for Linux buildRider Linden
2015-12-17MAINT-5977: Update cmake file to always include boost with LLCommonRider Linden
2015-11-10remove execute permission from many files that should not have itOz Linden
2013-04-19merge changes for DRTVWR-294Oz Linden
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2013-01-24merging in viewer-beta.Nyx Linden
Most of the merge was clean, a couple conflicts. Brought over a couple patches manually for llpolymesh.
2012-12-04Pull and merge viewer-developmentsimon@Simon-PC.lindenlab.com
2012-11-28SH-3563. Pull and merge from viewer-development. Modest code changes to fix ↵prep
alignment issue in llAppearance.
2012-10-11Updating linux build to gcc4.6Don Kjer
2012-09-07Further attempts to erradicate TCMALLOCsimon@Simon-PC.lindenlab.com
2012-09-07DRTVWR-209 Merge of viewer-development with SH-3316 drano-http code.Monty Brandenberg
Cmake files not merged correctly and had to be done by hand. New memory allocation made some memory usage tests in the llcorehttp integration tests no longer valid. Would like to work on LLLog sometime and get it to be consistent. Special flags needed for windows build of example program.
2012-08-02MAINT-515 FIX, CHOP-100 FIX - technically we are avoiding these issues ↵Brad Payne (Vir Linden)
rather than fixing them; changing llcommon to be statically linked avoids the symbol issues with llcommon.dll
2012-08-02MAINT-515 FIX, CHOP-100 FIX - technically we are avoiding these issues ↵Brad Payne (Vir Linden)
rather than fixing them; changing llcommon to be statically linked avoids the symbol issues with llcommon.dll
2010-12-15VWR-24254: Add support for using ld.gold on linux.Aleric Inglewood
To use ld.gold configure with: -DCMAKE_EXE_LINKER_FLAGS:STRING="-Wl,-use-gold". ld.gold links the viewer on my machine in 8 seconds, as opposed to 19 seconds with ld.bfd. Moreover, it uses a LOT less memory during linking (about 750 MB instead of 2.5 GB!). VWR-24254: Don't link with fontconfig on non-linux. While we already added fontconfig in the above patch, that code turned out to also be used by Windows and Darwin (contrary to the comments in the code). After looking at the history of commits and a discussion on IRC it was decided that the original coder (Kyle Ambroff <ambroff@lindenlab.com>) really meant (LINUX AND VIEWER) instead of (NOT LINUX OR VIEWER).
2009-07-28DEV-35399 - Making the server build llcommon.dll compatible.Mark Palange (Mani)
Now using RunBuildTest.cmake to run tut and lscript_lsl tests, inorder to set path to llcommon.dll Exported a few llcommon apis needed by server components/tests.
2009-07-09Brad already added the LLCOMMON_LINK_SHARED definition. I removed the broken ↵Mark Palange (Mani)
one I added and set the other one to ON by default.
2009-06-22Merge with viewer-2.0.0-3 branchBryan O'Sullivan
2009-06-21merge -r 122421-124917 viewer-2.0.0-2 -> viewer-2.0.0-3Steven Bennetts
ignore-dead-branch
2009-05-22DEV-27646 dll linkage for login module.Brad Kittenbrink
Ok, finally got this to a point where it doesn't break the build and I can check in. llcommon can be built as a shared library (disabled but can be enabled with cmake cache var LLCOMMON_LINK_SHARED. reviewed by Mani on tuesday (I still need to get his suggested changes re-reviewed)
2008-08-29Use target_link_libraries for llcommonBryan O'Sullivan
2008-06-02svn merge -r88066:88786 ↵Bryan O'Sullivan
svn+ssh://svn.lindenlab.com/svn/linden/branches/cmake-9-merge dataserver-is-deprecated for-fucks-sake-whats-with-these-commit-markers