| Age | Commit message (Collapse) | Author |
|---|
|
This changeset makes it possible to build the Second Life viewer using
Python 3. It is designed to be used with an equivalent Autobuild branch
so that a developer can compile without needing Python 2 on their
machine.
Breaking change: Python 2 support ending
Rather than supporting two versions of Python, including one that was
discontinued at the beginning of the year, this branch focuses on
pouring future effort into Python 3 only. As a result, scripts do not
need to be backwards compatible. This means that build environments,
be they on personal computers and on build agents, need to have a
compatible interpreter.
Notes
- SLVersionChecker will still use Python 2 on macOS
- Fixed the message template url used by template_verifier.py
|
|
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.
|
|
llversioninfo, remove extraneous python variable assignment in CMakeLists, run tests with INFO
|
|
converting to logging so that stdout from its command can be captured
cleanly
Make the default be to not print anything
|
|
|
|
|
|
A large negative return code doesn't do a human reader any good, even for
lookup purposes, because Microsoft's lookup tables list the hex representation
of that integer. So at least format the return code as hex.
Going further, we've captured the content of the web page
https://msdn.microsoft.com/en-us/library/cc704588.aspx
as windows-rcs.html. If we can parse that file, and if we understand the
structure of its table entries, and if the hex form of the actual return code
is in fact listed there, we can display the symbol name and description as
well as the hex return code.
All those maybes are to support refreshing the file from the URL above (or
wherever it might get moved) from time to time. Later versions of that file
might change in unexpected ways.
If we can't look up the hex rc, oh well, just display that to the user instead
of crumping.
|
|
A traceback from a Python script always makes people think there's a bug in
your script. Even when a test program fails to build, CMake often (always?)
tries to run it anyway, via our run_build_test.py script. For that case,
produce a straightforward error message -- rather than an OSError traceback
that doesn't even mention the program name!
|
|
|
|
|
|
|
|
Flushing print buffer before running actual test executable should make it
clearer which setup actions apply to which test run.
|
|
|
|
|
|
|
|
|
|
/Users/Aimee/Documents/Work/Linden-Lab/Development/viewer/convert/viewer-identity-evolution
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--HG--
branch : avatar-pipeline
|
|
--HG--
branch : avatar-pipeline
|
|
Because the details of RunBuildTest.cmake versus run_build_test.py had to be
changed in so many different places, introduce LL_TEST_COMMAND CMake macro (in
LLTestCommand.cmake) to encapsulate construction of the actual command line.
Use LL_TEST_COMMAND in LL_ADD_PROJECT_UNIT_TESTS, LL_ADD_INTEGRATION_TEST, the
big indra/test monolith and the various LslCompilerMacros.
Fix run_build_test.py to pass through the test executable's own options (e.g.
--touch, --output) without inspection. Defend it against the case when the
platform-specific library path environment variable doesn't yet exist. Make it
report errors only on nonzero test-program rc.
Remove RunBuildTest.cmake.
|
|
RunBuildTest.cmake can't handle pathnames containing spaces.
run_build_test.py accepts an arbitrary number of individually-quoted
command-line arguments, passing each through to Python's subprocess.call().
|
