At some point the INTEGRATION_TEST_llurlentry build changed so that the
library(ies) we attempted to stub out got linked in anyway, so that instead of
simplifying the test, the stubs broke it with "duplicate symbol" errors.
Commenting out the stubs permits the test program to succeed.
Instead, since gSavedSettings is an LLControlGroup and LLControlGroup derives
from LLInstanceTracker, just look up the LLControlGroup with canonical name.
The CMake directive that passes VIEWER_CHANNEL to the C++ compiler as
LL_VIEWER_CHANNEL was enclosing the VIEWER_CHANNEL value in double quotes. At
this point in history, those double quotes literally become part of the
LL_VIEWER_CHANNEL value, causing the viewer to construct a bad Viewer Version
Manager query containing those double quotes. Removing them fixes the query.
from autobuild.xml's darwin64 Release and ReleaseOS build (xcodebuild)
command.
-D passed to xcodebuild does NOT set CMake variables. These switches, in this
place, have never worked as intended.
When LL_BUILD is not in the environment at autobuild configure time, important
macros such as LL_WINDOWS aren't set. That means that platform-dependent
macros such as LL_TYPEOF() aren't defined, which can produce obscure errors
like this:
indra\llcommon\llunittype.h(51): error C2226: syntax error :
unexpected type 'S' (packages\llphysicsextensions\stub\LLPhysicsExtensionsStubImpl.cpp)
10> indra\llcommon\llunittype.h(52) :
see reference to class template instantiation 'LLResultTypeAdd<S,T>' being compiled
Make the CMake logic fail with a more readily-understood error in that case.
Turns out that without HAVOK, we can't build the PhysicsExtensions_TPV; but
the viewer's build.sh is unaware of CMake switches set in autobuild.xml.
Passing those CMake overrides in build.sh allows us to test that setting
elsewhere in build.sh to skip the PhysicsExtensions_TPV step -- instead of
failing the build.
If the only use of a variable is within llassert(), have to make the
declaration conditional on SHOW_ASSERT rather than guesswork about release
builds.
Someone evidently figured every static LLPipeline method should have at least
one void* parameter. There were methods requiring void* parameters that were
completely ignored.
More to the point, there were methods whose callers have a U32 in hand -- and
which want to use a U32 -- but which bizarrely forced callers to cast to void*
just so the method could cast back to U32. In a 64-bit compile, this isn't
merely pointless, it's erroneous. Change all such methods to accept U32;
remove (void*) casts from call sites.
While at it, fix LLPipeline API to use bool, true, false rather than their
obsolete all-caps predecessors. Once you eat that first potato chip... :-P
The signature for LLTracker::stopTracking() was silly: it accepted a void* for
the sole purpose of testing whether it was NULL. In other words, the parameter
was really a bool in void* clothing. Most callers passed NULL.
What got ugly was when you wanted to pass 'true', or a variable bool value.
Such values had to be cast to void*. In 64-bit land, the compiler correctly
flags that as extremely dubious practice.
But it's entirely unnecessary. Since stopTracking() wants a bool, change its
parameter to bool. Everybody wins.
(While at it, change a few related method params from BOOL to builtin bool.)
Since BOOL is simply a typedef for int, casting a 64-bit pointer to 32-bit int
is correctly diagnosed by the compiler as an error.
What works is to cast the pointer to (lowercase) bool, the builtin type, which
engages the compiler's test for "is this pointer NULL?"
LLWLAnimator stores a std::map<F32, LLWLParamKey>. But llwlanimator.h only
forward-declared LLWLParamKey, begging the question of how this ever compiled
on any previous platform.
LLWLParamKey was declared for real in llwlparammanager.h, so the obvious fix
is to #include "llwlparammanager.h" in llwlanimator.h. Unfortunately this
doesn't work because llwlparammanager.h already #includes "llwlanimator.h".
As the dependency is specifically on LLWLParamKey, which isa LLEnvKey, which
is declared in llenvmanager.h, move LLWLParamKey to llenvmanager.h. Then we
can #include "llenvmanager.h" in llwlanimator.h instead of merely forward-
declaring LLWLParamKey.
This migration compiles LLWLParamKey in a context in which LLTrans isn't
visible. It's not really clear why all LLWLParamKey's methods are inline, but
toString() -- the method that requires LLTrans -- isn't going to be fast in
any case. Break toString() out to llenvmanager.cpp, and #include "lltrans.h"
there.
Nat Goodspeed