Always search for python3[.exe] instead of plain 'python'. macOS Monterey no
longer bundles Python 2 at all.
Explicitly make PYTHON_EXECUTABLE a cached value so if the user edits it in
CMakeCache.txt, it won't be overwritten by indra/cmake/Python.cmake.
Do NOT set DYLD_LIBRARY_PATH for test executables! That has Bad Effects, as
discussed in https://stackoverflow.com/q/73418423/5533635. Instead, create
symlinks from build-mumble/sharedlibs/Resources -> Release/Resources and from
build-mumble/test/Resources -> ../sharedlibs/Release/Resources. For test
executables in sharedlibs/RelWithDebInfo and test/RelWithDebInfo, this
supports our dylibs' baked-in load path @executable_path/../Resources. That
load path assumes running in a standard app bundle (which the viewer in fact
does), but we've been avoiding creating an app bundle for every test program.
These symlinks allow us to continue doing that while avoiding
DYLD_LIBRARY_PATH.
Add indra/llcommon/apply.h. The LL::apply() function and its wrapper macro
VAPPLY were very useful in diagnosing the problem.
Tweak llleap_test.cpp. This source was modified extensively for diagnostic
purposes; these are the small improvements that remain.
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.
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.
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!
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().
Ansariel