[sldev] [SNOW][PATCH] Intent to commit

[Rob Lanphier]

On 07/22/2009 12:42 PM, Robin Cornelius wrote:
> Hey guys,
>
> Some patches i would like to roll in to snowglobe
>
> http://jira.secondlife.com/browse/SNOW-133
>
> Nice simple duplicate of what has already been applied to
> maint-viewer-14 but bugs me *every* time i do a windows build, as my
> python always seems to be in HKCU and not HKLM in the Win Registry so
> searching both should be default
>   

Yup, no brainer, and I see you've already committed after my nod.
>
> http://jira.secondlife.com/browse/SNOW-108
>
> A very simple patch to use get_time_of_day() for AMD64 Linux, as the get
> cpu count asm fails to return correct values and also fails on multicore
> systems.
>
> I would actually prefer to use the original patch and to always use the
> get_time_of_day() operating system call rather than hit the processor
> directly, but there is a 2nd version of the patch that leaves the
> original i386 code path untouched.
>
> Any comments, esp Tofu?
>   

I'll ask around about this one tomorrow.  It sounds good in theory, but
I'd like to understand the reason why things are the way they are now.

> And an extra patch that i just want comments on at this stage, not yet
> committing..
>
> http://jira.secondlife.com/browse/SNOW-125
>
> This allows the mozlib component to be used on standalone builds, and
> can do this in two ways. It searches for the mozlib components in the
> system libraries and user libraries locations /usr/lib and
> /usr/local/lib. And looks for three things. the libllmozlib.so library,
> the llmozlib2.h header and also searches for
> libprofdirserviceprovider_s.a file.
>
> Now the point of that last search is to determine the type of mozlib we
> are linking against. for the LL style original mozlib that file is
> present. For a standalone mozlib (either webkit or xulrunner based) that
> file is not present.
>
> At this stage this is more a help to standalone builders than anything
> and does not effect the main stream code release. At *some* point this
> will be quashed with the official qtwebkit stuff, although a very small
> amount may remain for standalone configurations.
>
> I've also included with that JIRA two examples of standalone mozlibs, a
> webkit based one and a xulrunner based one.
>   

This one looks interesting, and I think we should be able to accommodate
it without too much hassle, since it's largely a standalone build fix. 
I'm assuming you've double checked that non-standalone builds still
work, right?

Rob