[opensource-dev] any chance for storm-323?
Hi there, is there any chance that storm-323 gets some attention? I just logged in after a day, and roughly 30 subscribo messages made me first click accept or decline 30 times, and then made me click ok on the you have accepted.. resp. You have declined... popup. Whoever first thought of that second popup should be forced to spend not less than 1L$ for stuff that doesn't cost more than 1L$. If nothing else, I'd be happy with a few pointers on where to look, and I'll do it myself. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24247: develop.py configure still searches for the wrong header file when checking for Tut
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/#review49 --- indra/cmake/FindTut.cmake http://codereview.secondlife.com/r/39/#comment27 According to the CMake 2.8.1 man page, NO_SYSTEM_ENVIRONMENT_PATH makes find_path not only skip $PATH but also $INCLUDE. I think we should respect the latter when looking for headers. - Boroondas On 2010-12-18 09:01:35, Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/ --- (Updated 2010-12-18 09:01:35) Review request for Viewer. Summary --- There is no #include tut.h anywhere. The only includes are #include tut/tut.hpp (which is correct). Tut installs in prefix/include/tut/* among which the headerfile tut.hpp. The changed file, indra/cmake/FindTut.cmake, is only included when configured with --standalone (and thus only on linux). find_path searches in /usr/include and /usr/local/include anyway, so there is no way to add that. Adding the NO_SYSTEM_ENVIRONMENT_PATH stops it from reading the PATH environment variable and looking for tut/tut.hpp, which probably won't harm, but it simply makes no sense: we're looking for a headerfile, not an executable. Without this patch (and without creating a fake /usr/local/include/tut.h), I get the error: CMake Error at cmake/FindTut.cmake:26 (message): Could not find Tut Call Stack (most recent call first): cmake/Tut.cmake:8 (include) llmessage/CMakeLists.txt:13 (include) With the patch, it finds /usr/local/include/tut/tut.hpp as expected, setting TUT_INCLUDE_DIR to /usr/local/include, and it also finds (in my case) /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut/tut.hpp, setting TUT_INCLUDE_DIR to /usr/src/secondlife/viewers/snowstorm/viewer-development/include, since I have a symbolic link from /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut to ../linden/libraries/include/tut (which was installed manually with ./scripts/install.py tut) and I have the environment variable CMAKE_INCLUDE_PATH set to /usr/src/secondlife/llqtwebkit/install-imprudence/include:/usr/src/secondlife/viewers/snowstorm/viewer-development/include:/sl/usr/include. In other words, this allows developers to install headers whereever they want and use the API of cmake as it is intended, to find those headers. This addresses bug VWR-24247. http://jira.secondlife.com/browse/VWR-24247 Diffs - indra/cmake/FindTut.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/39/diff Testing --- Tested to see if it finds the header when installed in /usr/local/include as well in a path specified with CMAKE_INCLUDE_PATH. Note that you need to configure with --standalone in order to test this. Also note that unless tut is installed in /usr/local, and when you configure with -DLL_TESTS:BOOL=ON, it still won't compile because of another bug. I will submit a patch for that separately. Thanks, Aleric ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24247: develop.py configure still searches for the wrong header file when checking for Tut
On 2010-12-19 04:03:39, Boroondas Gupte wrote: indra/cmake/FindTut.cmake, line 10 http://codereview.secondlife.com/r/39/diff/1/?file=101#file101line10 According to the CMake 2.8.1 man page, NO_SYSTEM_ENVIRONMENT_PATH makes find_path not only skip $PATH but also $INCLUDE. I think we should respect the latter when looking for headers. I was aware of that, but I don't think that INCLUDE is ever used on linux. Not only not for any existing project, but also gcc doesn't honor it. It can hardly be considered to be a 'standard' (useful) search path for *system* header files when the default compiler isn't even using that environment variable. My guess was that this is more of a Windows(tm) thing. And indeed, Michelle just told me that on windows the command line compiler needs %INCLUDE% to function. So, I think that cmake searches PATH and INCLUDE because of Windows(tm). For example, Windows(tm) sets INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include. However, this code is only run on linux, where INCLUDE is not used, and it might even be harmful to search in PATH for header files. Like I said before, it probably won't hurt in this case (it's unlikely that anyone has an executable installed in their PATH called 'tut/tut.hpp') but I don't consider it to be the right thing for linux. That being said - in this particular case (for tut/tut.hpp) it will work just as fine with or without, so if that is a showstopper for Oz (or whoever has to add this patch) than I'd be ok with removing NO_SYSTEM_ENVIRONMENT_PATH and gambling that nothing will be found in PATH, instead of using the patch as-is: ignoring the windows INCLUDE on linux just like gcc ignores it. - Aleric --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/#review49 --- On 2010-12-18 09:01:35, Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/ --- (Updated 2010-12-18 09:01:35) Review request for Viewer. Summary --- There is no #include tut.h anywhere. The only includes are #include tut/tut.hpp (which is correct). Tut installs in prefix/include/tut/* among which the headerfile tut.hpp. The changed file, indra/cmake/FindTut.cmake, is only included when configured with --standalone (and thus only on linux). find_path searches in /usr/include and /usr/local/include anyway, so there is no way to add that. Adding the NO_SYSTEM_ENVIRONMENT_PATH stops it from reading the PATH environment variable and looking for tut/tut.hpp, which probably won't harm, but it simply makes no sense: we're looking for a headerfile, not an executable. Without this patch (and without creating a fake /usr/local/include/tut.h), I get the error: CMake Error at cmake/FindTut.cmake:26 (message): Could not find Tut Call Stack (most recent call first): cmake/Tut.cmake:8 (include) llmessage/CMakeLists.txt:13 (include) With the patch, it finds /usr/local/include/tut/tut.hpp as expected, setting TUT_INCLUDE_DIR to /usr/local/include, and it also finds (in my case) /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut/tut.hpp, setting TUT_INCLUDE_DIR to /usr/src/secondlife/viewers/snowstorm/viewer-development/include, since I have a symbolic link from /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut to ../linden/libraries/include/tut (which was installed manually with ./scripts/install.py tut) and I have the environment variable CMAKE_INCLUDE_PATH set to /usr/src/secondlife/llqtwebkit/install-imprudence/include:/usr/src/secondlife/viewers/snowstorm/viewer-development/include:/sl/usr/include. In other words, this allows developers to install headers whereever they want and use the API of cmake as it is intended, to find those headers. This addresses bug VWR-24247. http://jira.secondlife.com/browse/VWR-24247 Diffs - indra/cmake/FindTut.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/39/diff Testing --- Tested to see if it finds the header when installed in /usr/local/include as well in a path specified with CMAKE_INCLUDE_PATH. Note that you need to configure with --standalone in order to test this. Also note that unless tut is installed in /usr/local, and when you configure with -DLL_TESTS:BOOL=ON, it still won't compile because of another bug. I will submit a patch for that separately. Thanks, Aleric ___ Policies and (un)subscribe information available here:
Re: [opensource-dev] Review Request: VWR-24247: develop.py configure still searches for the wrong header file when checking for Tut
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/#review51 --- Ship it! Ah, I wasn't aware gcc ignores INCLUDE. In that case, the change is good as-is. - Boroondas On 2010-12-18 09:01:35, Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/ --- (Updated 2010-12-18 09:01:35) Review request for Viewer. Summary --- There is no #include tut.h anywhere. The only includes are #include tut/tut.hpp (which is correct). Tut installs in prefix/include/tut/* among which the headerfile tut.hpp. The changed file, indra/cmake/FindTut.cmake, is only included when configured with --standalone (and thus only on linux). find_path searches in /usr/include and /usr/local/include anyway, so there is no way to add that. Adding the NO_SYSTEM_ENVIRONMENT_PATH stops it from reading the PATH environment variable and looking for tut/tut.hpp, which probably won't harm, but it simply makes no sense: we're looking for a headerfile, not an executable. Without this patch (and without creating a fake /usr/local/include/tut.h), I get the error: CMake Error at cmake/FindTut.cmake:26 (message): Could not find Tut Call Stack (most recent call first): cmake/Tut.cmake:8 (include) llmessage/CMakeLists.txt:13 (include) With the patch, it finds /usr/local/include/tut/tut.hpp as expected, setting TUT_INCLUDE_DIR to /usr/local/include, and it also finds (in my case) /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut/tut.hpp, setting TUT_INCLUDE_DIR to /usr/src/secondlife/viewers/snowstorm/viewer-development/include, since I have a symbolic link from /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut to ../linden/libraries/include/tut (which was installed manually with ./scripts/install.py tut) and I have the environment variable CMAKE_INCLUDE_PATH set to /usr/src/secondlife/llqtwebkit/install-imprudence/include:/usr/src/secondlife/viewers/snowstorm/viewer-development/include:/sl/usr/include. In other words, this allows developers to install headers whereever they want and use the API of cmake as it is intended, to find those headers. This addresses bug VWR-24247. http://jira.secondlife.com/browse/VWR-24247 Diffs - indra/cmake/FindTut.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/39/diff Testing --- Tested to see if it finds the header when installed in /usr/local/include as well in a path specified with CMAKE_INCLUDE_PATH. Note that you need to configure with --standalone in order to test this. Also note that unless tut is installed in /usr/local, and when you configure with -DLL_TESTS:BOOL=ON, it still won't compile because of another bug. I will submit a patch for that separately. Thanks, Aleric ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: VWR-24251: Fix -DLL_TESTS:BOOL=ON on standalone when Tut is installed in a non-standard directory.
---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/44/
---
Review request for Viewer.
Summary
---
If tut/tut.hpp isn't installed in a standard include directory all tests
fail because the found include directory for tut isn't passed to the compiler.
This patch fixes this by passing it.
Note that using include_directories() in a Find*.cmake file is bad practise.
The correct way is to set an include dir variable and call
include_directories() once. It certainly doesn't work for the tests anyway
because the tests are all over the place and include_directories is on a
per folder basis. What is needed is to set it for each (test) target.
However, there is no TARGET_INCLUDE_DIRECTORIES. The closest thing that we
have is to set the COMPILE_FLAGS property for a target.
Fortunately, standalone is only used for linux, so we can just use
-I${TUT_INCLUDE_DIR} to get the effect we want.
This addresses bug VWR-24251.
http://jira.secondlife.com/browse/VWR-24251
Diffs
-
indra/cmake/LLAddBuildTest.cmake b0689af42a71
indra/cmake/Tut.cmake b0689af42a71
indra/test/CMakeLists.txt b0689af42a71
Diff: http://codereview.secondlife.com/r/44/diff
Testing
---
Tested with standalone and tut.hpp installed in a non-standard place *after
applying VWR-24247* of course.
All tests compile and pass (on linux 64bit).
Thanks,
Aleric
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: VWR-10579: Fix NDOF.cmake to do the right thing on standalone.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/45/ --- Review request for Viewer. Summary --- Only define -DLIB_NDOF=1 when NDOF is actually found, on standalone. While FindNDOF.cmake was added to the repository, it wasn't used. This addresses bug VWR-10579. http://jira.secondlife.com/browse/VWR-10579 Diffs - indra/cmake/NDOF.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/45/diff Testing --- I can't remember when I started using this, but it was long ago. I don't have libndofdev installed. I just installed Michelle's debian package libndofdev-dev and then it found it: -- Found NDOF: Library in '/usr/lib/libndofdev.so' and header in '/usr/include' Thanks, Aleric ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: VWR-24252: Find Qt4 with find_package on STANDALONE.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/46/ --- Review request for Viewer. Summary --- This patch has only effect on standalone. It searches for the Qt libs using the cmake provided FindQt4.cmake. I added an explicit test to check if QTDIR is set, it is set to the correct value (even LL got this wrong on their wiki, so it's apparently not obvious): As of Qt 4, Qt is found by calling qmake, NOT by looking at QTDIR. So, if you set QTDIR then it better be set to whatever qmake was found (using PATH as usual). While FindLLQtWebkit.cmake was added to the repository, it wasn't used for some reason... but it works perfectly. This patch uses it to find LLQtWebkit and then uses the resulting LLQTWEBKIT_LIBRARY and LLQTWEBKIT_INCLUDE_DIR in the right places. Finally, we also need to explicitly pass the Qt plugin libraries in order to link with them, so part of this patch adds the rules to do that (the foreach). This addresses bug VWR-24252. http://jira.secondlife.com/browse/VWR-24252 Diffs - indra/cmake/WebKitLibPlugin.cmake b0689af42a71 indra/llplugin/CMakeLists.txt b0689af42a71 indra/media_plugins/webkit/CMakeLists.txt b0689af42a71 Diff: http://codereview.secondlife.com/r/46/diff Testing --- I used this while working on adding plugin support to Imprudence, needing to debug into the Qt libs and llqtwebkit. I added support for multiple versions of llqtwebkit to imprudence (not just the one needed, but also newer versions of llqtwebkit). Needless to say that I needed this patch to work to find my (several) installations of Qt and llqtwebkit. Thanks, Aleric ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: SNOW-240: Fix libjson naming madness, for standalone.
---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/47/
---
Review request for Viewer.
Summary
---
On linux (and remember this is about standalone)
the libjson packages of distributions don't have this
complex compiler version baked into their name.
This patch fixes this issue by first searching for
libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so
and when that fails search for the system package
library file libjson.so.
This addresses bug SNOW-240.
http://jira.secondlife.com/browse/SNOW-240
Diffs
-
indra/cmake/FindJsonCpp.cmake b0689af42a71
Diff: http://codereview.secondlife.com/r/47/diff
Testing
---
It works :p (I have Michelle's debian package libjsoncpp0 installed, which
provides /usr/lib/libjson.so).
Thanks,
Aleric
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: VWR-24254: Add support for using ld.gold on linux.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/ --- Review request for Viewer. Summary --- To use ld.gold configure with: -DCMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-use-gold. See VWR-24254 for more details. This addresses bug VWR-24254. http://jira.secondlife.com/browse/VWR-24254 Diffs - indra/cmake/BerkeleyDB.cmake b0689af42a71 indra/cmake/LLCommon.cmake b0689af42a71 indra/cmake/LLPlugin.cmake b0689af42a71 indra/llwindow/CMakeLists.txt b0689af42a71 Diff: http://codereview.secondlife.com/r/48/diff Testing --- ld.gold links the viewer on my machine in 8 seconds, as opposed to 19 seconds with ld.bfd. Moreover, it uses a LOT less memory during linking (about 750 MB instead of 2.5 GB! (for viewer 1)). Since my machine locked up hard when I run out of memory (something with using an encrypted RAID for my swap), and compiling viewer 2 uses more than 3 GB, I couldn't compile viewer 2 at all anymore without this patch (and using ld.gold). And OMG this is fast! Thanks, Aleric ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24254: Add support for using ld.gold on linux.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/#review52 --- indra/cmake/LLCommon.cmake http://codereview.secondlife.com/r/48/#comment29 Is this removal related to ld.gold, too, or just general cleanup? - Boroondas On 2010-12-19 09:42:53, Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/ --- (Updated 2010-12-19 09:42:53) Review request for Viewer. Summary --- To use ld.gold configure with: -DCMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-use-gold. See VWR-24254 for more details. This addresses bug VWR-24254. http://jira.secondlife.com/browse/VWR-24254 Diffs - indra/cmake/BerkeleyDB.cmake b0689af42a71 indra/cmake/LLCommon.cmake b0689af42a71 indra/cmake/LLPlugin.cmake b0689af42a71 indra/llwindow/CMakeLists.txt b0689af42a71 Diff: http://codereview.secondlife.com/r/48/diff Testing --- ld.gold links the viewer on my machine in 8 seconds, as opposed to 19 seconds with ld.bfd. Moreover, it uses a LOT less memory during linking (about 750 MB instead of 2.5 GB! (for viewer 1)). Since my machine locked up hard when I run out of memory (something with using an encrypted RAID for my swap), and compiling viewer 2 uses more than 3 GB, I couldn't compile viewer 2 at all anymore without this patch (and using ld.gold). And OMG this is fast! Thanks, Aleric ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-10579: Fix NDOF.cmake to do the right thing on standalone.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/45/#review53 --- I'd prefer the following behavior: Let the user specify whether to use libndofdev or not. (Of course we'd have to agree on a default if nothing was specified). Then ... ... if libndofdev use has been enabled and libndofdev can be found, -- build with libndofdev support, thus with the joystick/spacenavigator features. ... if libndofdev use has been enabled but libndofdev can not be found, -- error out. (With some meaningful message) ... if libndofdev use has been disabled, -- don't build with libndofdev support, even if libndofdev is present. Rationale: If I *want* spacenavigator or joystick support, but libndofdev cannot be found (e.g. because I forgot to install it or because it was installed to a location that isn't searched), I'll get a heads-up at build time rather than having to figure out why stuff doesn't behave the way I want at runtime. Note: This would be analogous to how we currently handle FMOD, even although disabling FMOD -- other than disabling libndofdev -- doesn't result in unavailable viewer features. - Boroondas On 2010-12-19 07:54:19, Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/45/ --- (Updated 2010-12-19 07:54:19) Review request for Viewer. Summary --- Only define -DLIB_NDOF=1 when NDOF is actually found, on standalone. While FindNDOF.cmake was added to the repository, it wasn't used. This addresses bug VWR-10579. http://jira.secondlife.com/browse/VWR-10579 Diffs - indra/cmake/NDOF.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/45/diff Testing --- I can't remember when I started using this, but it was long ago. I don't have libndofdev installed. I just installed Michelle's debian package libndofdev-dev and then it found it: -- Found NDOF: Library in '/usr/lib/libndofdev.so' and header in '/usr/include' Thanks, Aleric ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: SNOW-240: Fix libjson naming madness, for standalone.
---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/47/#review54
---
Ship it!
Looks good.
Like this, it should continue working even if a system-wide installed libjson
uses the compiler-version-specific filename, like the gentoo ebuild from
Techwolf's portage overlay currently does. I guess all other distributions use
the plain name, so once this ebuild has been updated, we can even drop looking
for the compiler version specific filename in the standalone case completely.
- Boroondas
On 2010-12-19 09:19:37, Aleric Inglewood wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/47/
---
(Updated 2010-12-19 09:19:37)
Review request for Viewer.
Summary
---
On linux (and remember this is about standalone)
the libjson packages of distributions don't have this
complex compiler version baked into their name.
This patch fixes this issue by first searching for
libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so
and when that fails search for the system package
library file libjson.so.
This addresses bug SNOW-240.
http://jira.secondlife.com/browse/SNOW-240
Diffs
-
indra/cmake/FindJsonCpp.cmake b0689af42a71
Diff: http://codereview.secondlife.com/r/47/diff
Testing
---
It works :p (I have Michelle's debian package libjsoncpp0 installed, which
provides /usr/lib/libjson.so).
Thanks,
Aleric
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: SNOW-240: Fix libjson naming madness, for standalone.
On 2010-12-19 12:48:35, Boroondas Gupte wrote:
Looks good.
Like this, it should continue working even if a system-wide installed
libjson uses the compiler-version-specific filename, like the gentoo ebuild
from Techwolf's portage overlay currently does. I guess all other
distributions use the plain name, so once this ebuild has been updated, we
can even drop looking for the compiler version specific filename in the
standalone case completely.
Just wondering: Is there some reason behind the search order
(libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so first, then libjson.so) or
is that arbitrary? (I guess the systems where both are present are rare.)
- Boroondas
---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/47/#review54
---
On 2010-12-19 09:19:37, Aleric Inglewood wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/47/
---
(Updated 2010-12-19 09:19:37)
Review request for Viewer.
Summary
---
On linux (and remember this is about standalone)
the libjson packages of distributions don't have this
complex compiler version baked into their name.
This patch fixes this issue by first searching for
libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so
and when that fails search for the system package
library file libjson.so.
This addresses bug SNOW-240.
http://jira.secondlife.com/browse/SNOW-240
Diffs
-
indra/cmake/FindJsonCpp.cmake b0689af42a71
Diff: http://codereview.secondlife.com/r/47/diff
Testing
---
It works :p (I have Michelle's debian package libjsoncpp0 installed, which
provides /usr/lib/libjson.so).
Thanks,
Aleric
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24254: Add support for using ld.gold on linux.
On 2010-12-19 11:07:57, Boroondas Gupte wrote: indra/cmake/LLCommon.cmake, line 11 http://codereview.secondlife.com/r/48/diff/1/?file=113#file113line11 Is this removal related to ld.gold, too, or just general cleanup? Oops. That was supposed to be a general cleanup, inspired by the fact that llcommon isn't including apu.h (the header that is being looked for for APRUTIL_INCLUDE_DIR). But because of your question I double checked, and although /usr/include/apr-1.0 contains apr_*.h files and apu_*.h files, about half of the apr_*.h files belong to aprutil! And we DO use those (ie, apr_base64.h). I'll change the patch to not remove that tomorrow. - Aleric --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/#review52 --- On 2010-12-19 09:42:53, Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/ --- (Updated 2010-12-19 09:42:53) Review request for Viewer. Summary --- To use ld.gold configure with: -DCMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-use-gold. See VWR-24254 for more details. This addresses bug VWR-24254. http://jira.secondlife.com/browse/VWR-24254 Diffs - indra/cmake/BerkeleyDB.cmake b0689af42a71 indra/cmake/LLCommon.cmake b0689af42a71 indra/cmake/LLPlugin.cmake b0689af42a71 indra/llwindow/CMakeLists.txt b0689af42a71 Diff: http://codereview.secondlife.com/r/48/diff Testing --- ld.gold links the viewer on my machine in 8 seconds, as opposed to 19 seconds with ld.bfd. Moreover, it uses a LOT less memory during linking (about 750 MB instead of 2.5 GB! (for viewer 1)). Since my machine locked up hard when I run out of memory (something with using an encrypted RAID for my swap), and compiling viewer 2 uses more than 3 GB, I couldn't compile viewer 2 at all anymore without this patch (and using ld.gold). And OMG this is fast! Thanks, Aleric ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Daily Scrum Summary - Friday, December 17
Whoops, sorry this is late! Friday, December 17, 2010 General Notes
--
- Merge Monkey of the Day: Oz
- Merov needs review in STORM-151!
Team Status
--
Merov Linden
--
*PAST*
- STORM-745 : Produce comprehensive perf baseline: Created a set of
images to compress and a huge baseline for Mac.
- STORM-744 : Add unit tests to llkdu: Reactivated the broken
llimage/tests/llimageworker_test.cpp unit tests and fixed it.
*FUTURE*
- STORM-745 : Produce comprehensive perf baseline: Complete that work for
Mac.
- STORM-744 : Add unit tests to llkdu: Finish fixing the llimage test and
add new ones to llkdu.
*IMPEDIMENTS*
- none
Oz Linden
--
*PAST*
- Merge Monkey
- merged some fixes, created a couple of MM tools
- Learning corner cases in codereview
- Lindens vs Residents snowball fight
- Fixing more internal documentation
*FUTURE*
- libcurl test
- Merge Monkey
- Autobbuild audits so we can publish it as open source
*IMPEDIMENTS*
- none
Q Linden
--
*PAST*
- Reviewed several items in CR tool and other JIRAs and commented on one,
but merov beat me to most of them
- Reviewed wiki for Merov
- Several meetings
- Ship 2.4
- A lot of OOO medical; sorry.
*FUTURE*
- OOO and some triage, maybe
- Meetings
- OOO next Mon for PGI hackathon
*IMPEDIMENTS*
- holiday and medical OOO will limit my productivity through New Year
Esbee Linden
--
*PAST*
- Lots of meetings
- Snowstorm team meeting
- Review integration queue
- Viewer 2.4 release stuff
- Finalize Viewer 2.4 blog post and publish
*FUTURE*
- Lots of meetings
- Review integration queue
- Upload sketches of saved layouts
- VWRs to check on
- VWR-21493
- STORM-525
- STORM-529. It was re-resolved as no repro.
- STORM-702. Caused issues based on fix. Let's chat more with PE about
this. (Nyx is going to take a look at this)
- Review VWR-16569 - Will review. Jonathan wants this one.
- Review Jonathan's work list
- Touch base w/Taka on STORM-398
- See comments on STORM-713
- Think about what to do with VWR tickets assigned to ProductEngine (I'm
thinking we just un-assign these - need to review the tickets first though)
*IMPEDIMENTS*
- Time
Paul ProductEngine
--
- OOO - sick
Seth Productengine
--
*PAST*
- BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard
combinations
- WIP. Got unit tests working with new directory iterator. The
iterator doesn't handle changes in directory contents for now.
*FUTURE*
- BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard
combinations
*IMPEDIMENTS*
- Story (STORM-28) As a User, I want the ability to send my calling card
to others.
- Waiting for more details.
Andrew Productengine
--
*PAST*
- Normal task STORM-2 (As a User, I want to set my own default views with
specific UI layout so I can tailor my Viewer experience to the activities
I'm most interested in).
- Completed first raw implementation of save and load. Will prettify
it a little tomorrow, test and make some temporary simple UI for it.
*FUTURE*
- STORM-2. Finish first raw version of the fix. Estimate - 1 day. So
it would be good to have design of UI and answer from Q about files
(STORM-777) as soon as possible to implement the final version next week.
-
- Estimate - 1 day.
*IMPEDIMENTS*
- STORM-2 - No design for UI ( STORM-753 (Design the UI for viewer saved
layouts))
- No reply from Q to letter regarding STORM-777 (Design the file format
for layout information and discuss it).
Vadim Productengine
--
*PAST*
- Bug STORM-529 (Undo feature missing from BUILD menu):
- Fixed.
- Bug STORM-776 (unable to change permissions to no trans on item in
avatar inventory):
- Reviewed and tested Wolfpup's patch.
- Bug STORM-410 (Region and parcel SLApps are displayed in non-human
readable format):
- Created two subtasks. Implemented the first one and assigned the
second one to Esbee.
*FUTURE*
- Bug STORM-446 (CLicking on the
secondlife:///app/classified/{UUID}/about SLapp does not display the
details for the specified classified in the People side tray).
- Bug STORM-511 (User is not able to view full name of group in title of
group notification).
*IMPEDIMENTS*
- Need feedback from Esbee in:
- STORM-702 (Make it possible to wear partial outfits).
- STORM-797 (Parcel SLURL rendering).
- What to do with VWR tickets assigned to ProductEngine Team?
https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hiderequestId=13071
