summaryrefslogtreecommitdiff
path: root/indra
AgeCommit message (Collapse)Author
2023-07-18SL-18837: Try waiting a couple seconds before hdiutil detachNat Goodspeed
to try to avoid "Resource busy" errors from hdiutil.
2023-07-18SL-18837: Ditch inactive llrand.cpp LL_USE_SYSTEM_RAND code.Nat Goodspeed
LL_USE_SYSTEM_RAND has been disabled since June 2008; that code only clutters the implementation we actually use.
2023-07-17SL-18837: Lowercasing pathname for string compare is Windows-only.Nat Goodspeed
2023-07-17SL-18837: Clean up some redundancy in llrand.cpp.Nat Goodspeed
2023-07-17SL-18837: Merge branch 'actions' into actions-build-shNat Goodspeed
2023-07-10SL-18837: Windows failures in setWorkingDirectory(): C: vs. c: (sigh)Nat Goodspeed
Normalize the case of the name of the temp directory for string comparison.
2023-07-10SL-18837: Disable APR_LOG for now, but leave notes for the future.Nat Goodspeed
2023-07-10SL-18837: Revert "Force llprocess_test and llleap_test to use just 'python'."Nat Goodspeed
Turns out that the pathname of the Python executable wasn't the issue. This reverts commit 7dc6211ad5ea83685a35c6fff740278343aa8b9d.
2023-07-08SL-18837: Force llprocess_test and llleap_test to use just 'python'.Nat Goodspeed
On GitHub Windows runners, trying to make build.yaml set PYTHON=python in the environment doesn't work: integration tests still fail with "Access is denied" because they're still trying to execute the interpreter's full pathname. Instead, make llprocess_test and llleap_test detect the case of GitHub Windows and override the environment variable PYTHON with a baked-in string constant "python".
2023-07-08SL-18837: Set APR_LOG once for the whole jobNat Goodspeed
instead of a new value for each LLProcess::create() invocation. Since the internal apr_log() function only looks at APR_LOG once per process, the first test (which succeeded, hence no log file dump) left the log file open with that same original pathname. Resetting the APR_LOG environment variable for subsequent runs only made the new code in llprocess_test look for files that were never created.
2023-07-08SL-18837: Don't use LLDir, use NamedTempFile::temp_path.Nat Goodspeed
Remove llcommon circular dependency on llfilesystem, which doesn't work for this case anyway.
2023-07-07SL-18837: Ditch unreferenced name of caught exceptionNat Goodspeed
2023-07-07SL-18837: Hook in LLDir to allow reading APR log file.Nat Goodspeed
2023-07-07SL-18837: Fix spurious semiNat Goodspeed
2023-07-07SL-18837: Fix "lldir.h" #includeNat Goodspeed
2023-07-07SL-18837: Coax APR to log LLProcess launch attempts; show log file.Nat Goodspeed
2023-07-07SL-18837: Partially revert e933ace, keeping useful tweaks.Nat Goodspeed
Introducing indirection via test_python_script.py did NOT address the "Access is denied" errors on GitHub Windows runners.
2023-07-07SL-18837: Try to bypass Windows perm problem with Python indirection.Nat Goodspeed
2023-07-07SL-18837: Try putting generated Python scripts in RUNNER_TEMP dir.Nat Goodspeed
The claim is that the Windows Python interpreter is integrated somehow with the OS such that a command line that tries to run Python with a script that "looks suspicious" (i.e. in a system temp directory) fails with "Access denied" without even loading the interpreter. At least that theory would explain the "Access denied" errors we've been getting trying to run Python scripts generated into the system temp directory by our integration tests. Our hope is that generating such scripts into the GitHub RUNNER_TEMP directory will work better. As this test is specific to Windows, don't even bother running Mac builds.
2023-06-28SL-18837: Make LLVersionInfo::getBuild() S64 for GitHub run IDs.Nat Goodspeed
2023-06-07Attempt to port some build.yaml improvements from DRTVWR-559 over to actions ↵Brad Linden
branch
2023-06-06SL-18837: Concat path part with / rather than +=.Nat Goodspeed
Using concatenation appends the intended filename to the parent directory name, instead of putting the filename in the parent directory.
2023-06-06SL-18837: On Windows, NamedTempFile must convert from wstringNat Goodspeed
2023-06-06SL-18837: Ditch Boost.Phoenix implicit lambda syntax.Nat Goodspeed
It's cool to be able to write 'arg1 << "stuff" << var ...;' for a lambda accepting a std::ostream reference, but cascading compile errors mean it's no longer worth trying to make that work -- given actual C++ lambdas. Also clean up a lingering BOOST_FOREACH() and a boost::bind() while at it.
2023-06-06SL-18837: Make NamedTempFile name template compatible with Python.Nat Goodspeed
The recommended template uses hyphens; change to underscores to be valid Python temp module names.
2023-06-06SL-18837: NamedTempFile back to std::function, use boost::phoenix <<Nat Goodspeed
It seems the problem addressed by aab769e wasn't some synergy between Boost.Phoenix and Boost.Function, but rather the lack of a Phoenix header file introducing operator<<().
2023-06-05SL-18837: NamedTempFile must still disambiguate string literals.Nat Goodspeed
2023-06-05SL-18837: Make NamedTempFile revert to boost::functionNat Goodspeed
from std::function, since some consumers still use (e.g.) boost::phoenix::placeholders::arg1 to generate an inline callable.
2023-06-05SL-18837: Try giving temp Python scripts a .py extension.Nat Goodspeed
On GitHub Windows Actions runners, we're getting permissions errors trying to tell the Python interpreter to run a NamedTempFile script. Try using NamedExtTempFile to give each such script a .py extension.
2023-06-05SL-18837: Use Boost.Filesystem for NamedTempFile, instead of APR.Nat Goodspeed
2023-06-05SL-18837: Followup to 19e9e8c: global Boost.Bind placeholdersNat Goodspeed
do not need 'using' directive, given BOOST_BIND_GLOBAL_PLACEHOLDERS.
2023-06-05SL-18837: Try to silence cascade of Boost.Bind warning messages.Nat Goodspeed
2023-06-05SL-18837: Windows APR 1.7.2 requires MS rpcrt4.dll.Nat Goodspeed
2023-06-05SL-18837: Bump the granularity of WorkQueue timing tests.Nat Goodspeed
On a low-powered GitHub Mac runner, the system doesn't wake up as soon as it should, and we get spurious "too late" errors. Try a bigger time increment.
2023-06-05SL-18837: #include <array> in several sources that need it.Nat Goodspeed
It seems we're no longer implicitly inheriting <array> from some other [set of] header file[s]. Where we use std::array, bring it in explicitly.
2023-06-05SL-18837: We no longer build Windows apr-iconv -- don't reference.Nat Goodspeed
With VS 2022 on Windows GitHub Actions runners, we can't build apr_suite at all with the upstream .sln / .vcxproj files, so we had to switch to "experimental" CMake support. However there's no CMakeLists.txt file for apr-iconv, so the Windows package omits that library.
2023-06-02SL-18837: Don't include a version-specific Boost.Regex header.Nat Goodspeed
Let the umbrella <regex.hpp> header make that decision.
2023-06-02SL-18837: Boost.Bind _1, _2 placeholders are no longer global.Nat Goodspeed
This was a longstanding complaint: that Boost shouldn't dump the (somewhat mysterious) _1, _2 et al. names into the global namespace. Recent Boost has fixed that, requiring 'using namespace boost::placeholders;' if you want to use them unqualified.
2023-06-02SL-18837: Don't try to copy long, specific libnghttp2.14.19.0.dylib.Nat Goodspeed
The package doesn't include that any more.
2023-05-19DRTVWR-558: Merge branch 'main' of secondlife/viewer into actionsNat Goodspeed
2023-05-17Increment viewer version to 6.6.13Nat Goodspeed
following promotion of DRTVWR-577
2023-05-09SL-19660 Merge pull request #199 from beqjanus/mainakleshchev
BUG-233797/233798 - fix blackout when u/w fog_density < 0
2023-05-04Merge remote-tracking branch 'origin/zap-LLSDArray' into DRTVWR-577-maint-SAndrey Lihatskiy
2023-05-03SL-19647: Eliminate LLSDArray entirely.Nat Goodspeed
Newer C++ compilers have different semantics around LLSDArray's special copy constructor, which was essential to proper LLSD nesting. In short, we can no longer trust LLSDArray to behave correctly. Now that we have variadic functions, get rid of LLSDArray and replace every reference with llsd::array().
2023-05-03DRTVWR-575: Replace some LLSDArray() usage with llsd::array().Nat Goodspeed
It seems newer compilers have a different interpretation of exactly when to engage LLSDArray's copy constructor. In particular, this assignment: some_LLSD_map[key] = LLSDArray(...)(...)...; used to convert the LLSDArray object directly to LLSD; now it first calls the custom copy constructor, which embeds the intended array within an outer array before assigning it into the containing map. The newer llsd::array() function avoids that problem because what it returns is already an LLSD object. Taking inventory of LLSDArray assignments of that form turned up a number of workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is both simpler and more readable. Tip of the hat to Chorazinallen for surfacing this issue! (cherry picked from commit bb718155bddfbe7007029a0c9e69a4a98615f14d)
2023-05-02Merge branch 'main' into mainBeq Janus
2023-05-02Merge branch 'main' into DRTVWR-577-maint-SAndrey Lihatskiy
2023-05-02Increment viewer version to 6.6.12Vir Linden
following promotion of DRTVWR-539
2023-04-30BUG-233797/BUG-233798 -ve underwater fog density causes blackout.Beq
2023-04-18SL-19591 Prompt user to save current settings as Graphics Preset before ↵Andrey Lihatskiy
enabling AutoFPS