viewer_manifest.py had LLManifest.prefix() calls starting with '..' (or
os.pardir, same thing) which failed with new prefix() calling conventions.
Explicitly starting with os.path.join(self.args['build'], os.pardir, etc.)
where applicable works much better.
Turns out that having multiple (source, build, artwork) prefix stacks isn't
such a good idea after all. Many of our LLManifest.path() directives use
wildcards -- and if _any files_ match the specified wildcard from a prefix
stack other than what you had in mind, viewer_manifest will silently,
cheerfully do the Wrong Thing.
There is a good reason why all existing LLManifest.prefix() calls exclusively
used src= and/or dst= instead of build=.
The way prefix("path_fragment") or prefix(src="path_fragment") has always
worked is that unless you explicitly specify dst="", it adds "path_fragment"
to the source AND dest prefix stacks!
The most recent refactoring of viewer_manifest.py failed to copy CEF because
it involved prefix(src="../some lengthy path fragment") -- forgetting to
specify dst="" -- which added "../some lengthy path fragment" to the dest
prefix stack -- which put it outside the viewer install staging area
altogether.
Having been bitten too many times by forgetting to add prefix(dst=""), we
remove the necessity. The prefix() src=, build= and dst= prefix stacks are now
completely independent. Add src_dst= keyword argument for when you DO want to
add the same path fragment to both the source and dest prefix stacks.
("Explicit is better than implicit.")
Change all existing calls accordingly.
Now that the build prefix stack no longer tracks the src prefix stack, we were
failing to pick up some things from the build area because NOBODY ever used
build=, relying entirely on src= to point both to stuff in the source tree and
stuff in the build tree. Try to use build= appropriately.
If that proves too confusing, we might eliminate the separate build and
artwork (!) prefix stacks entirely, requiring callers to reset the src stack
explicitly when switching back and forth.
Direct BugSplat to send crash reports without prompting, on both Windows and
Mac.
Add a mechanism by which code called after LL_ERRS() can retrieve the fatal
log message string. (How did the crash logger extract that for Linden crash
logging?)
Add that fatal message to crash reports on Windows. But as BugsplatMac is
engaged only on the run _after_ the crash, we no longer have that message in
memory.
Also add user name and region location to Windows crash reports. On Mac, (a)
we don't have the information from the previous run and (b) BugsplatMac
doesn't provide an API to attach that information to the crash report.
Add Mac logging to indicate the success or failure of sending the crash
report. Add Windows logging to indicate we're about to send.
The Breakpad symbol-file upload in the viewer's build.sh was failing on
BugSplat builds since we weren't generating Breakpad symbol files. That upload
was conditional on RELEASE_CRASH_REPORTING, so my first approach was to set
RELEASE_CRASH_REPORTING=OFF for BugSplat builds. Unfortunately that symbol
also propagates down into C++ compiles, and in llappviewerwin32.cpp, both
Breakpad and BugSplat crash reporting is conditional on it. So that change
inadvertently turned off the C++ logic to engage BugSplat.
Stop forcing RELEASE_CRASH_REPORTING=OFF for BugSplat builds. Instead, make
the Breakpad symbol-file upload check the BUGSPLAT_DB variable as well.
Add #pragma messages to llappviewerwin32.cpp so we can detect whether it's
being built for Breakpad or BugSplat or neither.
Nat Goodspeed