Removed function to delete use stored password file
Removed no longer used RemoveCacheFilesDP from language files
Added message to English language file for prompt when asking to remove user files
-Note: this needs translations in other languages added
Functionality change: deletion of entire skins folder to prevent issues when
an XML file is deleted from the installer, but left on the hard drive after upgrade
Note: Showing details adds a lot of overhead and will slow down the processes,
but allows the user the option of seeing what is going on. Usefull for errors that occure.
To be more accurate, this changeset doesn't actually eliminate the dependency:
it eliminates the use cases for the llifstream / llofstream feature that
requires it.
Currently you can construct an llifstream or llofstream from an open LLFILE*
file handle (or, except on Windows, an int file descriptor). But rather than
containing a streambuf implementation based on FILE*, llfile.h relies on the
fact that the Windows std::filebuf happens to support that as a nonstandard
extension; also on a nonstandard GNU extension __gnu_cxx::stdio_filebuf<char>.
To move from GNU libstdc++ to clang's libc++ (the direction on Mac), we could
code a streambuf that supports FILE*. But before doing that, it's worth asking
whether anyone actually uses this questionable feature.
In fact there were only two methods: LLWearable::exportFile() and importFile()
-- and only one call to either, in LLViewerWearable::saveNewAsset(). The code
in saveNewAsset() opened the LLFILE* immediately before calling exportFile(),
meaning we could reasonably push the open operation down into exportFile().
That logic was complex anyway due to the need for the caller to close the
LLFILE* regardless of the success of the exportFile().
Change LLWearable::exportFile() and importFile() to accept a std::string
filename rather than an open LLFILE*. Change LLViewerWearable::saveNewAsset()
to simply call exportFile(filename) rather than horsing around with an LLFILE*
handle. (This improves the code in another way too: it encapsulates the need
to open the relevant file in binary mode. Previously, each caller had to
remember to do that.)
To prevent inadvertent reintroduction of ll[io]fstream(LLFILE*) code, add
llstream_LLFILE preprocessor macro (default 0) to control access to the
relevant constructors. Also suppress rdbuf() override, the only method whose
signature references llstdio_filebuf.
A skip() stating that we don't yet understand why the test fails is implicitly
an open action item. This one isn't open. Save future developers the research.
LLLoginInstance has a test hook setNotificationsInterface(), used by
lllogininstance_test.cpp to redirect notifications through a dummy
LLNotificationsInterface implementation. Certain of LLLoginInstance's
MandatoryUpdateMachine state classes need to post notifications too; but until
now they directly called LLNotificationsUtil::add(). In the production viewer,
this should (!) be the same as calling through LLLoginInstance::mNotifications
-- but it broke two of the LLLoginInstance unit tests, so they were skipped.
Since MandatoryUpdateMachine's constructor is already passed the invoking
LLLoginInstance&, make it store the reference. Add MandatoryUpdateMachine::
getNotificationsInterface(), which forwards to new LLLoginInstance::
getNotificationsInterface(). Change LLNotificationsUtil::add() calls in
MandatoryUpdateMachine state classes to call through mMachine's
getNotificationInterface() instead.
This allows us to remove #include "llnotificationsutil.h" from
lllogininstance.cpp, also that #include plus stub LLNotificationsUtil::add()
implementation from lllogininstance_test.cpp.
Finally, it allows us to remove the skip() calls from the two unit tests.
Until we can propagate the corresponding buildscripts changes, we must
explicitly put AUTOBUILD in proper form. For now, assume that AUTOBUILD has
not yet been normalized.
A particular LLInitParam::TypeValuesHelper specialization is derived from a
different TypeValuesHelper specialization. The subclass constructor
TypeValuesHelper(...) has previously forwarded the call to its base-class
constructor with:
TypeValuesHelper(val): TypeValuesHelper(val) {}
This is the first time I've looked at that; I'm a bit surprised that previous
compilers blithely accept it, and apparently understand the intent. gcc 4.7
complains that we would need to turn on -std=c++11 to support delegating
constructors; obviously the second TypeValuesHelper is now assumed to be the
class being defined, rather than its base class.
Fortunately the class already has typedefs for both specializations, fully
qualified with all template parameters, so I simply replaced the second
TypeValuesHelper reference with base_t.
The former is the real .so, to which libalut.so is only a symlink. We were
packaging the symlink without including its target.
(This appears to have changed since our last Vivox drop for Linux.)
Rider Linden