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.
Nicky