Specifically, Second Life.app is now mostly just a wrapper. Its Contents/
Resources contains nested Launcher.app (the VMP) and Viewer.app (the viewer
itself). Most of what used to be in the top-level Second Life.app has been
relocated to the embedded Viewer.app. VMP stuff has of course been extracted
to Launcher.app. The top-level Second Life.app executable is now a tiny script
that runs Launcher.app. This structure permits different icons and different
Dock flyover text for the launcher and the viewer, hopefully ameliorating a
certain amount of user confusion about the dual icons.
This requires a corresponding VMP change: on macOS, the VMP must now find both
its resources and the viewer executable by walking up from Launcher.app and
down again into its sibling Viewer.app.
Since Dock flyover text is determined by the embedded app names, allow Product
to change these at will. That means we should be able to tweak exactly one
variable assignment to change either of those embedded app names, without
having to chase down other references scattered throughout the source repo.
For that reason, create top-level trampoline SL_Launcher script dynamically:
it must reference the launcher app by name. That means we must also perform
(the equivalent of) chmod +x on that generated script.
The one mystery surrounding this restructuring is that without a top-level
Frameworks symlink pointing to the embedded Viewer.app's Frameworks directory
(where CEF lives), CEF refuses to start: no splash screen, no MoP. Perhaps we
can fix that someday.
Use Python's bundled plistlib to generate Info.plist files for the embedded
applications.
Reorganize stray code stanzas to try to help the structure of the code more or
less resemble the structure of the desired result.
Add ViewerManifest.relpath() method to determine the relative path from a
specified base to the target path. If base omitted, assumes get_dst_prefix()
-- handy for creating symlinks. Determining exactly the right number of
os.pardir instances to concatenate into the relative pathname for a symlink
(or an install_name_tool stamp) was tedious, fragile and unobvious, difficult
to desk-check. Using relpath() should make all that more robust.
Migrate symlinkf() from free function to ViewerManifest method, refactoring
into _symlinkf_prep_dst() and _symlinkf(), adding relsymlinkf(). This lets us
add convenience features such as prepending get_dst_prefix() to the dest (the
place where we want to create the symlink), defaulting dest to the basename of
target and ensuring that the parent of that dest already exists -- as with
LLManifest.path(). Moreover, since it makes no sense whatsoever to create an
absolute symlink to some path on the build machine, relsymlinkf() creates
every symlink relative to dirname(dest). That, in turn, lets us eliminate a
certain amount of boilerplate around existing calls. (Also, since we now
ensure the parent directory exists, scrap the logic to diagnose "nonexistent
parent directory.")
Make llmanifest.LLManifest.run_command() not pass shell=True to subprocess,
thereby permitting (requiring) the list form rather than the string form.
Change all existing calls to list form. This makes calls more readable, for
two reasons. First, many of the arguments are taken from script variables;
these can simply be dropped into the list instead of indirecting through
string interpolation. Second, it eliminates the need to manually escape
individual arguments, since subprocess promises to honor the distinction
between list elements.
Also fix LLManifest.put_in_file() to ensure the containing directory exists.
Consolidate some viewer_manifest.py redundancy, e.g. copying the same set of
ten DLLs from either of two directories depending on Release vs. Debug.
LLManifest.prefix() dates back to before Python had a 'with' statement or the
notion of a context manager. That's why every prefix() call requires a
corresponding end_prefix() call.
Existing usage is of the form:
if self.prefix(...some args...):
self.path(...)
...
self.end_prefix()
The use of an 'if' statement is solely to allow the coder to indent the
statements between the self.prefix() call and the corresponding call to
self.end_prefix() -- there is no intention to make that code conditional.
self.prefix() unconditionally returned True to facilitate that usage.
But now that we have the 'with' statement, this all feels a little silly. Make
prefix() return an instance of a context-manager class so that it's reasonable
to say instead:
with self.prefix(...some args...):
self.path(...)
...
and have the Right Things happen simply by leaving the 'with' block.
The only tricky part is code to preserve compatibility with old-style usage:
* The context manager has a __nonzero__() method so that if it's tested in an
'if' statement, it can unconditionally return True.
* On leaving the 'with' block, rather than simply popping the top of each
prefix stack, the context manager restores its length to the same length it
had before that prefix() call. This allows for (erroneous but hardly
unlikely) usage of the form:
with self.prefix(...some args...):
self.path(...)
...
self.end_prefix()
Restoring the previous length makes the context manager insensitive to whether
or not end_prefix() has popped the most recent prefix() entries.
* do not redirect stderr to stdout
* catch errors generated in platform specific code and display them more nicely
* run_command no longer captures output (only used in one place;
replaced that with direct use of subprocess)
viewer_manifest.py uses its base-class llmanifest.LLManifest.put_in_file()
method to create several different files in the install image being
marshalled. I based the logic to create settings_install.xml on that example.
Unfortunately I failed to notice that after every existing call, the script
also explicitly appended the newly-created file to self.file_list... which
only matters on Windows. file_list is fed to the NSIS installer.
Change put_in_file() method to implicitly append to self.file_list.
Change every existing viewer_manifest.py call to pass new put_in_file(src=)
param instead of explicitly appending to self.file_list.
Previous viewer_manifest.py unconditionally created Mac symlinks for all expected
.dylib files. Recent change to revert to statically linking llcommon means we
no longer build libllcommon.dylib, therefore we no longer copy it, therefore
any symlink to that library will be broken by definition.
Change to create symlinks for .dylib files that were successfully copied.
Turns out that some (many?) wildcard LLManifest.path(wildcard) calls are "just
in case": sweep up any (e.g.) "*.tga" files there may be, but no problem if
there are none.
Change path() logic so it tries the next tree (source, artwork, build) if
either a specific (non-wildcard) filename doesn't exist, as now, OR if a
wildcard matches 0 files in the current tree. This continues to support "just
in case" wildcards, while permitting wildcards to work in the artwork and
build trees as well as the source tree.
Use a more specific exception than ManifestError for missing file. Only in
that case should we try the next tree. Any other ManifestError should
propagate.
viewer_manifest.py's Linux_i686Manifest class has contained directives to copy
library files with names like (e.g.) "libapr-1.so.0.4.2", which means that
every update to any such library requires messing with viewer_manifest.py.
But LLManifest.path() claims to support wildcards, and it's more robust to
specify "libapr-1.so*" instead.
Unfortunately LLManifest.path()'s wildcard support only used to work for files
in the source tree (vs. the artwork tree or the build tree). The logic in
path() tries each tree in turn, relying on an exception to make it try the
next tree. This exception was raised for a nonexistent specific filename --
but it never used to raise that exception for a wildcard matching 0 files.
Instead it would simply report "0 files" and proceed, producing an invalid
viewer install.
Raise that exception for a wildcard matching nothing. This forces path() to
consider the artwork tree and the build tree, permitting us to use wildcards
in library names.
Define an exception specific to LLManifest: ManifestException rather than the
generic Python RuntimeException. Make it a subclass of RuntimeException so any
existing callers expecting to catch RuntimeException will continue to work.
This lets us capture the command's stderr as well as stdout. I've been
perplexed recently by errors from Mac SetFile commands that didn't report
stderr.
Nat Goodspeed