| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Generalize Copy3rdPartyLibs.cmake to eliminate some clone-and-tweak redundancy.
|
|
|
|
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.
|
|
|
|
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.)
|
|
into eventual viewer package -- instead of finding them in the viewer build
tree. Also update Windows to current slplugins package build.
|
|
|
|
|
|
The .dylib files in the Linux Vivox package were erroneous to start with;
while the affected changeset bypassed copy errors, it too was wrong. Now that
the Linux Vivox package contains Linux .so files, revert to the correct
filenames to copy.
|
|
|
|
since we're not building them as part of the viewer build any more.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To this point, we've been failing the build with a Python OSError traceback,
which is less than ideal.
|
|
|
|
This only applies to the Windows package so far, because so far only the
Windows package exists.
|
|
Ensure that AUTOBUILD is always in native path syntax on every platform.
Remove local build.sh logic to infer AUTOBUILD: either the generic build.sh
has set it properly, or scream for help.
Since cygwin bash scripts need a cygwin-syntax path to autobuild, convert to a
local 'autobuild' variable using shell_path.
Remove kludges in other languages involving cygdrive twiddling.
|
|
|
|
The contents are extracted, but not yet built into the viewer installer.
|
|
The any() builtin was introduced in Python 2.5. Not only is its intent
clearer, but it handles the case of zero items -- which the reduce(or_)
construct does not. Sporadically we've seen exceptions from
generate_breakpad_symbols.py when reduce(or_, ...) is given zero items. This
masks the actual error (failure to dump symbols? failure to read them?),
masquerading as a bug in the Python script.
|
|
|
|
Unicode version of NSIS, not the one from the NULLSOFT site
|
|
|
|
|
|
|
|
|
|
|
|
There was a comment in CMakeLists.txt left over from 2009 (!) about commenting
out the unit test for llcapabilitylistener. Fortunately we've since reinstated
the test as an integration test, but the comment was never removed -- until now.
|
|
|
|
|
|
|
|
|
|
https://svn.boost.org/trac/boost/ticket/10864
I've used boost::lambda with boost::function in a number of creative ways over
the years. But the clang 6 shipped with Xcode 6 seems to have somehow broken
lambda + function in Boost 1.57. boost::phoenix is a partial workaround.
Sadly, lambda's comma-operator overload doesn't seem to be supported,
necessitating a couple ugly workarounds.
With real lambdas now supported by current compilers, I'm sure the Boost
community has little incentive to repair the lambda + function problem.
Presumably we'll be able to use such features ourselves Real Soon Now...
|
|
(long long round) in VS2013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
