[opensource-dev] Explorations in develop.py

[Philippe (Merov) Bossut]

Hi Ricky,

On Tue, Jun 22, 2010 at 8:36 PM, Ricky <kf6kjg at gmail.com> wrote:

> Looking through develop.py, I spied the following lines:
>
> 281-        elif self.arch() == 'x86_64' and self.is_internal_tree():
> 282-            # the viewer does not build in 64bit -- kdu5 issues
> 283-            # we can either use openjpeg, or overhaul our viewer
> to handle kdu5 or higher
> 284:            # doug knows about kdu issues
> 285-            return ['server-' + platform_build]
>
> Using svn blame, I found that these lines arrived into
> /linden/projects/2010/snowglobe/trunk/indra/develop.py at the time of
> the creation of this project at r3145.  I didn't checkout and search
> up the parent branches (wish svn had a way to do this easily!)
> Because of this, I am unable to tell whether this is still valid or
> otherwise.  Any enlightenment? Maybe a JIRA so I can see what the
> current status is?  My initial searches have turned up nothing,
> however, I may not be using the correct keywords...
>

This is still valid script and, as one can see in the code, only triggered
for internal (that is, internal to Linden Lab) repositories. What that means
is that we (LL) always build with KDU internally and we haven't made the
effort to support the newest KDU lib that would handle 64bits architecture.

In Snowglobe (and other external tree), folks can (and do) build 64bits
viewers and use openjpeg for texture compression/decompression.


> My memory is bugging me with the thought that a switchover to OpenJPEG
> has already happened... If so, then section of code should likely be
> updated.  Of course, it seems from the conditional that is is only
> about 64 bit builds of the Linden internal branch.  However, the
> reasoning given here may not be valid any more, and could possibly be
> replaced with a reference to a JIRA issue, maybe even the Linux 64bit
> build meta http://jira.secondlife.com/browse/VWR-13793 .
>

I don't understand what you mean by "switchover to openjpeg". Support for
openjpeg is in the viewer since a long time, I think since the early days
of  open sourcing the viewer, pre Snowglobe for sure. Both KDU and openjpeg
are supported though. The choice is made at runtime by loading libraries:
the viewer tries to load llkdu first and, if it fails, uses the openjpeg
default implementation. See LLImageJ2C::openDSO() for llkdu loading and
switch to default (openjpeg). openjpeg is statically linked and implemented
in llimagej2coj.cpp.

Cheers,
- Merov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100625/911d361e/attachment.htm