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.
Introduce new header file llappviewermacosx-for-objc.h to publish for
llappdelegate-objc.mm and other Objective-C++ consumers the free functions in
llappviewermacosx.cpp they consume. These were never before declared in any
header file. Apparently, to date, we've been trusting to luck that
Objective-C++ will infer the correct signature from calls -- and that the
calls are correct with respect to the function definitions. :-P
This gives us a place to introduce a new getLogFilePathname() function to
query LLDir. (We don't simply #include "lldir.h" because of the pervasive use
of BOOL in viewer headers; BOOL means something very different in Objective-C++.)
It might point to an uninitialized LLDir, but that's a whole separate problem,
one that wouldn't be detected by checking for nullptr. If we hit that, time to
change to an LLSingleton.
Set our CMake 'product' variable to VIEWER_CHANNEL. This probably has far-
reaching implications, but it seems the expedient way to keep everything self-
consistent. Use ${product} in the DARWIN VIEWER_EXE_GLOBS used for Breakpad
symbol dumping instead of hardcoding 'Second Life'.
The Breakpad symbol dumping stanza was enclosed in nested (but not indented)
conditions. To these we add another condition: don't bother if we're using
BugSplat. Unify all three into a single horrendous outermost expression.
Fix the MACOSX_BUNDLE_INFO_STRING, and hence CFBundleGetInfoString, to
VIEWER_CHANNEL as well.
Our CMake MACOSX_BUNDLE_SHORT_VERSION_STRING was never used before -- we were
erroneously using MACOSX_BUNDLE_LONG_VERSION_STRING in the Info-SecondLife.plist
template even for CFBundleShortVersionString. Looks like a classic copy/paste
error. Fix that; also use four-part version number instead of three-part.
With those two changes, we shouldn't need to patch the top-level Info.plist in
viewer_manifest.py any more.
viewer_manifest.py still needs to move the viewer executable(s) to the
embedded viewer app bundle, but it no longer needs to rename the real
executable to the channel name since we've already dealt with that in CMake
land. This lets us unify the code that picks the biggest of those executables
in the first and second viewer_manifest.py runs.
Nat Goodspeed