| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
when compiling newview using GCC.
|
|
Streaming is not working yet, though. Until it's made sure that the
dynamic library and plugins needed are on the paths the executable is
expecting them to be.
|
|
This reverts commit f4c8949ac66d08263845f60a7cef2ecb9c77079b.
|
|
Though without this, the viewer had still successfully built, and I
didn't experience any run-time problem yet. This commit is to anticipate
any directory picker related problem later, cause it seems very likely
that this is needed.
|
|
|
|
instead of letting it fallback to the default which would be Window's.
When using the default, somehow the viewer launched with no colours even
after resetting ~/.secondlife/user_settings/settings.xml.
|
|
|
|
The function takes a boolean argument anyway. This is so we don't get
GCC int in bool context warning which would be treated as an error.
|
|
Otherwise GCC would treat them as errors, if not suppressed.
|
|
|
|
in order to get rid of undefined references to
`LLFilePicker::getOpenFileModeless(LLFilePicker::ELoadFilter, void (*)(bool, std::vector<std::string, std::allocator<std::string> >&, void*), void*)'
`LLFilePicker::getMultipleOpenFilesModeless(LLFilePicker::ELoadFilter, void (*)(bool, std::vector<std::string, std::allocator<std::string> >&, void*), void*)'
`LLFilePicker::getSaveFileModeless(LLFilePicker::ESaveFilter, std::string const&, void (*)(bool, std::string&, void*), void*)'
The UI has been relying on modeless file operations. UI implementations
for Linux would fall within the GTK scope, and there haven't been
implementations for these three methods yet. Even know they're
defined using member functions that do nothing, and return boolean
false.
|
|
|
|
Mostly following Linux.
|
|
Including v4 would cause conflicts.
|
|
|
|
For now. Maybe.
|
|
as it's not implied on some platforms that std::array would be
unrecognised.
|
|
The style conventions aren't really being followed that the different
styles of using tabs or spaces as indentations lead to GCC considering
them as misleading.
It's better to just fix them (but as little as possible as to minimise
this fork difference from upstream) than to supress the warnings from
being treated as errors.
|
|
On GCC, compiling against a recent GTK2 version would stop on deprecated
pre-processors.
|
|
|
|
|
|
|
|
It's deprecated anyway.
|
|
|
|
Since the CMakeLists.txt includes some same .cmake files as the viewer,
I think the project might as well be a part of the Linden libraries
code. And for now is put under llprimitive (might not be consistent, in
fact the opposite, with they way llplugin relates to slplugin), but I
think this way results the least change, and it still works.
The differences include:
- all files (common llphysicsextensions headers to be included by
library users and the stub implementation files) are put inside one
directory, and the CMakeLists.txt is adjusted accordingly;
- modernised CMakeLists.txt, so include_directories are now implied by
target_link_libraries;
- some file name fix;
- add_library is not explicitly set to STATIC;
|
|
following promotion of DRTVWR-580
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/llcharacter/llkeyframemotion.cpp
# indra/newview/llfilepicker.cpp
|
|
following promotion of DRTVWR-577
|
|
|
|
|
|
|
|
Newer C++ compilers have different semantics around LLSDArray's special copy
constructor, which was essential to proper LLSD nesting. In short, we can no
longer trust LLSDArray to behave correctly. Now that we have variadic
functions, get rid of LLSDArray and replace every reference with llsd::array().
|
|
Fix typos in floater_scene_load_stats.xml and llviewerstats.cpp
|
|
It seems newer compilers have a different interpretation of exactly when to
engage LLSDArray's copy constructor. In particular, this assignment:
some_LLSD_map[key] = LLSDArray(...)(...)...;
used to convert the LLSDArray object directly to LLSD; now it first calls the
custom copy constructor, which embeds the intended array within an outer array
before assigning it into the containing map.
The newer llsd::array() function avoids that problem because what it returns
is already an LLSD object.
Taking inventory of LLSDArray assignments of that form turned up a number of
workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is
both simpler and more readable.
Tip of the hat to Chorazinallen for surfacing this issue!
(cherry picked from commit bb718155bddfbe7007029a0c9e69a4a98615f14d)
|
