| Age | Commit message (Collapse) | Author |
|---|
|
the cef-bin and dullahan 3p packages but they were not copied to the right place - now they are
|
|
But since that viewer-manager build depends on being able to read the
application name from build_data.json (to locate the shortcut), add an AppName
key to build_data.json.
|
|
|
|
|
|
Back out misguided attempt to overwrite $PROGRAMFILES with $PROGRAMFILES64.
|
|
thereby avoiding strange Windows requirement for elevated privilege.
|
|
This should eliminate any confusion due to a Standard user needing to elevate
to Admin privileges, since from that point on Windows tells the running
program the current user is that Admin. Bypass all that.
|
|
|
|
viewer_manifest.py was signing updater.exe within the package, and then
signing the installer executable itself, but not the actual viewer executable.
Add that.
|
|
by replacing the viewer's baked-in BugsplatMac.framework @rpath path with one
based on @executable_path.
|
|
|
|
|
|
|
|
|
|
|
|
We expect the viewer-manager package to be self-contained: we expect it to
bring with it any Python packages it requires. We no longer force developers
to wrap third-party Python packages as autobuild packages.
|
|
|
|
|
|
But change shortcuts and registry entries and everything else back to the real
viewer executable, so that every subsequent run directly launches the viewer.
Eliminate SL_Launcher references from viewer_manifest.py.
|
|
codesign claims to succeed, but spctl says:
/Volumes/Second Life Installer/Second Life Test.app: rejected
(the code is valid but does not seem to be an app)
Why not? Display what's in Second Life.app/Contents on the mounted
sparseimage: show Info.plist, list Frameworks, MacOS, Resources.
|
|
|
|
|
|
The start of viewer_manifest.DarwinManifest.construct() is a path() call to
copy the whole viewer tree from where CMake constructs it. The comment is:
"(this is a no-op if run within the xcode script)." Unfortunately, for unclear
reasons, this has recently started nesting Second Life.app within the Second
Life.app directory, and even to multiple levels. When that happens, copying
the outermost .app directory to the sparseimage in order to convert to dmg
runs out of room because we're trying to pack multiple copies of the whole
viewer tree into the fixed-size sparseimage.
But if it works to simply skip that entire initial copy operation, so much the
better.
|
|
We'll try to address the Mac app bundle name discrepancy a different way.
|
|
|
|
The relationship to MAINT-9047 is that we hope this will improve the behavior
of Mac code signing.
|
|
|
|
windows
|
|
|
|
|
|
|
|
copies files into the right place after a build impacted the fragment of code that copies over the VLC runtime files (Libvlc.dll, libvlccore.dll and the VLC plugins dir) and they never made it to the right place. This change restores that copy
|
|
|
|
|
|
|
|
This evidently makes all the difference as to whether the app is considered
launchable.
|
|
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.
|
|
|
|
|
|
The LLManifest.copy_action() method ensures that the destination directory for
any file copy exists before trying to copy the file, specifically so we don't
have to clutter the business logic with tests and explicit directory creation.
Remove redundant os.makedirs() stanzas.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now that LLManifest.prefix() supports use as a context manager:
with self.prefix(...):
...
convert existing calls to that form.
This was an interesting exercise because it surfaced at least two places where
the indentation did not match the self.prefix() nesting, plus another place
where existing code was undented without a self.end_prefix() call. (That last
was an uncaught logic bug.) This underscores the value of using a SINGLE
consistent, idiomatic mechanism to limit the scope of each self.prefix() call.
|
|
|
|
|
|
To support that, enhance path_optional() to accept wildcards and return the
expanded filenames.
|
