Depth of moving from LL prebuild scripts to pure standalone Snowglobe (meaning true standalone not based on any system library, not cmake's standalone build for linking with systems libs.) Good candidate to keep in bitbucket.

Shared library version of Snowglobe viewer. Would a patch be accepted and maintained if it only allowed this options and exposed a few calls? Maybe -DSHARED:BOOL=TRUE

If we turn the viewer into a prebuilt/distributable shared library, would this increase chances of support for a 64 bit version?

(I have lots more for another day... lol)

Unity3D devs make a move in-world, yet they won't support Linux (even though they say multiplatform) -- could LL fill this gap with (hint) distributable shared library that'll eventually be narrowed down to an embeddable renderer. Pretty much already there if all inventory related functions were separated from the scene, which neither one needs really to know about the other in a constant frame loop.

pJIRA SNOW project: Can we please get a "2.1" (and maybe also already a "2.2") option for "Affects/s Verion(s)" and "Fix Version(s)"?

Your topic here!

If we run out of topics before the end of the meeting, we'll triage Snowglobe or Open Source specific Jira Issues from the list below.

Jira Issues

After discussion, r3349 was reverted. Do these still need discussion (e.g. for viewer-external)?:

I did 15 commits today... mostly for standalone and a lot for having libraries in weird places (aka, support for CMAKE_INSTALL_PATH and CMAKE_LIBRARY_PATH)... but now I can build and run 1.4 and 2.1, standalone and non-standalone :/...

They DOES shift the meaning of 'common' in llcommon :p. Clearly it meant common between server and viewer in the past (pre-plugins). And now it would really start to mean 'common between viewer and plugins'.

After my fixes of today, you can just set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to some viewer specific directory (I use $PROJECTBASE/include). I then have a link from there to the libraries in linden/libraries/include (ake, tut). That way I can pick up libs from libraries/include without the risk to pick up libs that I don't want.

Which brings us to the question: what happens to commits made to the snowglobe repository? Is there some offical traject for them where each of them are judged on whether or not they are wanted in viewer-external, and if so, are merged upstream?

(I think all of my 16 or-so commits of today should be merged upstream- standalone or not... but my *feeling* about it is that if I don't keep bugging you they will surely be /dev/null-ed regarding upstream).