| 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.
|
|
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.
|
|
I don't know at what point the skip() was introduced, but that test now passes
even on Windows.
|
|
|
|
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.
|
|
|
|
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.)
|
|
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.
|
|
|
|
|
|
|
|
Use the same signatures as for the other platforms.
|
|
For some reason, after the upgrade to Boost 1.57, gcc 4.6.3 has trouble with
the boost::lambda::_1 usage in stringize.h. This is consistent with other
cases we've encountered in which Boost.Lambda appears to be unmaintained and
losing its compatibility with other libraries. Fortunately Phoenix provides a
functional equivalent, albeit spelled differently.
|
|
|
|
|
|
|
|
|
|
|
|
To this point, we've been failing the build with a Python OSError traceback,
which is less than ideal.
|
|
|
|
The new toolchain may (!) have fixed a longstanding bug in LLLeap / APR when
we try to pump large volumes of data through a Windows named pipe using APR
nonblocking I/O. This used to fail pretty consistently because the APR
nonblocking write call would sometimes spuriously return "would block" when in
fact the data buffer was completely written; the caller would later retry,
which of course would duplicate some of the data in the pipe. Preliminary
experiments with VS 2013 suggest this may have been resolved. This changeset
is to propagate the experiment to a wider range of Windows systems; we may
need to revert it if in fact the bug persists.
|
|
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
|
|
|
|
|
|
|
|
ms_sleep() calls and adjust expectations accordingly
|
|
|
|
|
|
|
|
|
|
It appears that our trouble was due to a cygwin-style path in the AUTOBUILD
environment variable, and that changeset 0e0bd8b546ad fixed it.
|
|
|
|
|
|
|
