| Age | Commit message (Collapse) | Author |
|---|
|
by replacing the viewer's baked-in BugsplatMac.framework @rpath path with one
based on @executable_path.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to attach user settings file and static debug info file to Mac crash reports,
as well as SecondLife.log, just like Windows crash reports.
|
|
breaks
Improve the implementation so that escaping is computed only once
|
|
|
|
Specifically, introduce an LLEventMailDrop("LoginSync"). When the updater
detects that an update is required, it will post to that rendezvous point.
When login.cgi responds with login failure, make the login coroutine wait (a
few seconds) for that ping from the updater.
If we receive that ping and if it contains a "reply" key, make the fail.login
listener respond to the updater with an indication of whether to proceed with
update.
If both login.cgi and the updater concur that an update is required, produce a
new confirmation message for the user and then (once user responds) tell the
updater to proceed. Otherwise, produce the usual login-failure message and
tell the updater never mind.
Introduce LLCoro::OverrideConsuming to provide temporary save/restore of the
set_consuming() / get_consuming() flag. It's a good idea to set the consuming
flag when retrieving data from an LLEventMailDrop.
|
|
The updater is required to survive beyond termination of the viewer that
launched it so it can launch the next installer, or a replacement viewer.
Having the old viewer forcibly terminate it on shutdown would be counter-
productive.
Introduce a third LLLeap::create() overload taking LLProcess::Params, which
gives access to autokill, cwd and other options previously unsupported by
LLLeap. Reimplement the existing create() overloads in terms of this new one,
since LLLeapImpl::LLLeapImpl() is already based on LLProcess::Params anyway.
Use LLProcess::Params in LLAppViewer::init() to specify the updater process,
setting autokill=false.
Refactoring LLLeapImpl() apparently involved engaging an LLInitParam::Block
feature never before used: had to drag operator() into Multiple from its base
class TypedParam (as has been done in other TypedParam subclasses).
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
This avoids having to tokenize a single string, avoiding swallowing
backslashes in Windows pathnames in the mistaken belief they're escape
characters. Alternatively, it avoids us having to double-escape them or
convert them to forward slashes or whatever.
|
|
|
|
|
|
|
|
|
|
Clearly it's not obvious to maintainers that on the Mac, getAppRODataDir()
returns the app's Resources directory: in a number of places the code starts
with the executable directory and appends "../Resources" to find that.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
viewer_manifest is run twice by CMakeLists.txt: once with --actions=copy and
once with the default actions copy and package. The fact that we (try to) move
the Mac viewer executable both times has confused things on a number of
occasions. Currently it's bollixing our attempt to run dsymutil on the
executable so we can package up the Mac symbols for both codeticket and
BugSplat.
Introduce DarwinManifest.is_rearranging() that tests whether either "package"
or "unpacked" is in self.args["actions"], echoing an earlier test. Make
several things conditional on that, notably moving the executable.
|
|
|
|
|
|
|
|
|
|
If this theory is correct, setting VIEWER_APP_EXECUTABLE to VIEWER_BINARY_NAME
and then referencing VIEWER_APP_EXECUTABLE instead of VIEWER_BINARY_NAME
confuses CMake as to the filename involved. <eyeroll/>
|
|
Seems VIEWER_SYMBOL_FILE arrives from build.sh as a relative pathname, so
passing that pathname to tar when we run tar with WORKING_DIRECTORY confuses
it. But if we use tar's -C switch, we can achieve the effect we want (no
leading directory prefixes in the tarball) without WORKING_DIRECTORY. Thing
is, we have to run the desired directory through cygpath first, which is why
we went with WORKING_DIRECTORY in the first place.
|
|
|
