| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Introducing indirection via test_python_script.py did NOT address the "Access
is denied" errors on GitHub Windows runners.
|
|
|
|
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.
|
|
Having observed installer upload failures, I discovered the warning in
actions/upload-artifact/README.md about multiple concurrent jobs trying to
post the same pathname to the same artifact name. Try to disambiguate
artifacts not only for different platforms, but for different jobs running on
the same platform.
This change also reflects my understanding that an artifact is (effectively) a
distinct zip file that can contain multiple uploaded files. Because we'll want
to download metadata without having to download enormous installers, create a
separate metadata artifact per platform. Similarly, symbol files can get large:
use a third distinct artifact for symbol files.
But with those artifacts defined, leverage actions/upload-artifact's ability
to upload multiple paths to the same artifact. In build.sh, define bash arrays
installer, metadata, symbolfile and set up so that, on exit, each is written
to a GITHUB_OUTPUT variable with the corresponding name. This involves a
little magic to get macOS bash 3 to indirectly access an array.
These multi-line output variables are then used to drive the upload-artifact
step for each of the defined artifacts.
|
|
|
|
and use them instead of codeticket addoutput to pass GitHub xxx_name, xxx_path
outputs to build.yaml.
Add upload steps to build.yaml to try to upload build products identified in
build.sh.
|
|
We suspect that autobuild incorrectly prioritizes AUTOBUILD_CONFIGURATION over
its command-line -c switch. The autobuild command to build the TPV package for
llphysicsextensions specifies -c Tpv (the configuration in the specified
config file), but with AUTOBUILD_CONFIGURATION=Release set, autobuild fails:
"ERROR: no configuration for build configuration 'Release' found"
|
|
That doesn't seem to be the distinction between TC builds and GH builds.
Instead, we'll try unsetting AUTOBUILD_CONFIGURATION.
This reverts commit d62e7039dafe4a49d548225203785eeda0eeb44a.
|
|
Bug in autobuild 3.9.2? The TC viewer build can successfully build
llphysicsextensions/autobuild-tpv.xml, but the previous GH actions build
failed: "no configuration for Release found" despite -c Tpv. The difference
seems to be that we used 'pip3 install autobuild' from PyPI, whereas the TC
buildscripts setup clones secondlife/autobuild branch v3 and installs from
that repo.
|
|
Also pretend novel arch value MINGW6 is really CYGWIN so we'll recognize it.
|
|
|
|
|
|
|
|
and use these variants for GitHub builds.
|
|
|
|
|
|
|
|
|
|
This reverts commit 996ea03d874c714f312c1bfbafda3dddc2172a39.
|
|
branch
|
|
|
|
|
|
|
|
which should only affect Windows unit tests, but should hopefully improve our
chances that Windows unit tests will succeed.
|
|
|
|
Using concatenation appends the intended filename to the parent directory
name, instead of putting the filename in the parent directory.
|
|
|
|
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.
|
|
The recommended template uses hyphens; change to underscores to be valid
Python temp module names.
|
|
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<<().
|
|
|
|
from std::function, since some consumers still use (e.g.)
boost::phoenix::placeholders::arg1 to generate an inline callable.
|
|
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.
|
|
|
|
do not need 'using' directive, given BOOST_BIND_GLOBAL_PLACEHOLDERS.
|
|
The Python child processes used by llprocess_test.cpp and llleap_test.cpp need
the Python llsd module to communicate with the C++ parent process.
Also set LOGFAIL and BUGSPLAT_DB environment variables.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
Let the umbrella <regex.hpp> header make that decision.
|
|
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.
|
|
The package doesn't include that any more.
|
