[opensource-dev] Product Backlog addition request: Build fixes for 64bit out-of-source

[Boroondas Gupte]

  User Story

As a Funtoo Linux (a Gentoo variant) 64bit user and volunteer viewer
developer, I want to build Snowstorm with the same build mode I already
use(d) for Snowglobe:

* native (i.e. 64bit)
* standalone
* out-of-source

I'd like to be able to do this for all three, Release, RelWithDebug and
Debug mode.


Rationale

This specific choice of build mode might require some explanations. (If
you don't think so, just skip this section. ;-) )


  Why native (64bit)?

* Why not? (OK, that might not be a too good argument.)
* 64bit builds will also have a 64bit |bin/SLPlugin|, which, other
  than the 32bit version, will be able to use my already installed
  (64bit) GStreamer
  o Gentoo (and thus also Funtoo) allows a "multilib" setup that
installs some important libraries in both 64bit and 32bit
versions, so that most 32bit applications can be run.
However, GStreamer isn't one of these libraries, so one
would probably need a 32bit chroot with 32bit GStreamer to
be able to use it from a 32bit |bin/SLPlugin|. That or I
could dual boot or use a VM.
* So I see when changes in the source break 64bit.
  o If those can be corrected right away, whenever LL decides to
also provide 64bit binaries, the source will be ready to
build them.


  Why standalone?

For those who don't know what the (confusingly named) 'standalone' build
mode implies, see Compiling the viewer (Linux) > What does 'Standalone'
mean?

on our wiki. So why use it?

* LL provides no 64bit version of the prebuilt libraries, so when
  wanting to build 64bit, I don't have much of a choice here, anyway.
* So I see whether version changes of the used libraries will break
  something. Often, the code can be prepared to work well with
  various versions of a library, see e.g. SNOW-737
  .
* So I see whether changes in the source break standalone.
  o Most packagers of the Viewer for Linux distributions will
base their packages on standalone builds. So keeping
standalone flawless means making their task a bit easier.


  Why out-of-source?

What is it and how do I do it? See What is an "out-of-source" build?
 at
the FAQ on the CMake wiki. As for the why:

* A pristine source tree makes it easy to see your own
  modifications, especially addition of yet untracked files (which
  will show up in |hg status| but not |hg diff|).
* Maintain builds with different settings from a single source tree
  in separate directories.
* Easy to do clean rebuilds by just deleting and re-creating the
  build dir.
* Once again, to see when it is/gets broken.

Of course, I don't want to imply that everyone should build like I do.
To the contrary, the more different combinations of build settings,
operation system setup etc. are used (and thus tested and hopefully
fixed if broken), the more robust and flexible our build system and
source will become in the end.


  What's already done

As some of you might know, I've been working on collecting patches and
changesets on pJIRA and SVN that allow me to build
lindenlab/viewer-development
 with the settings
above. I've applied them to my repository at
http://bitbucket.org/boroondas/snowstorm-development , ported/modified
them where necessary. I also had Techwolf port some of his own patches.
(Available on his repo
. Thanks Techwolf!)

The final result, merged with the many changes that came from upstream
meanwhile, can be found at the current tip (i.e. rev a0292ef8)

of my repository.


Remaining issues

* SNOW-508  (missing
  |glh/glh_linear.h|)
  o Can be worked around manually by just copying the file into
the right place.
  o Has a proper solution (for standalone) for this been
established yet and I just missed an additional step needed
for it? If so, please let me know.
* Tests fail because the test binaries can't load the required
  shared libraries
  o Work around this by disabling the tests: Set |LL_TESTS| to
|FALSE|.
* When building for the first time or after cleaning the build dir,
  make fails like this near the end:
>   [100%] Building CXX object
>   newview/CMakeFiles/secondlife-bin.dir/llappviewerlinux_api_dbus.o
>   Linking CXX executable secondlife-bin
>   [100%] Built target secondlife-bin
>   Scanning depend

Re: [opensource-dev] Product Backlog addition request: Build fixes for 64bit out-of-source

[Boroondas Gupte]

 On 08/26/2010 02:37 PM, Boroondas Gupte wrote:
> PS: Looks like upstream got some more changesets this morning, I'll
> provide a merge ASAP.
Here you go:
http://bitbucket.org/boroondas/snowstorm-development/changeset/5f58bebfb4ce

happy testing
Boroondas
___
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] Product Backlog addition request: Build fixes for 64bit out-of-source

[Aleric Inglewood]

Hey Boroondas,

not withstanding testing-- I'd like to urge you to get this checked in
ONE related SNOW-* jira at a time (except when they are totally related
of course).

Just wanted to express my "concerns" that all of these changes would
end up as a single commit.

I'd prefer to see them committed per corresponding jira patch, and if the
final commit is not near-100% the same as the original SNOW patch then
that should be detailed clearly in the commit comment.

Thanks!
Aleric

On Thu, Aug 26, 2010 at 4:02 PM, Boroondas Gupte
 wrote:
>  On 08/26/2010 02:37 PM, Boroondas Gupte wrote:
>> PS: Looks like upstream got some more changesets this morning, I'll
>> provide a merge ASAP.
> Here you go:
> http://bitbucket.org/boroondas/snowstorm-development/changeset/5f58bebfb4ce
>
> happy testing
> Boroondas
> ___
> 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
>
___
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] Product Backlog addition request: Build fixes for 64bit out-of-source

[Boroondas Gupte]

 Hi Aleric

On 08/26/2010 06:20 PM, Aleric Inglewood wrote:
> not withstanding testing-- I'd like to urge you to get this checked in
> ONE related SNOW-* jira at a time (except when they are totally related
> of course).
>
> Just wanted to express my "concerns" that all of these changes would
> end up as a single commit.
I'm not quite sure what you mean by "a single commit" ... "a single
pull", maybe? I /have/ created a separate changeset (a.k.a. "commit")
for almost each patch or SVN changeset I've used. (Everything else would
probably be impossible to review.) The relevant pJIRA issue IDs should
be listed in the commit messages, as well as the SVN commits (if any).

After CG mentioned Daggy Fixes
 on IRC, I used that
technique, so apart from my first few sequential commits (and the
sequential commits I pulled from Techwolf) everything should be easy to
cherry-pick and/or backport.

Or did you mean I should have merged the single commits individually
into upstream instead of merging them together and merging the result
into upstream? If so, why? (It shouldn't matter, as far as I know.)

> I'd prefer to see them committed per corresponding jira patch,
(see above)

> and if the
> final commit is not near-100% the same as the original SNOW patch then
> that should be detailed clearly in the commit comment.
I think I've used "Boroondas Gupte (original patch by )
" as 'author' for stuff I had to modify and "Boroondas Gupte
(patch by ) " (i.e. without 'original') for
patches I could apply essentially as-is. I don't know how consistent I
was at that, so I'd have to check that.

If required, I can re-do the commits with better indication of the
differences from the original patches, but with hg not allowing any
history rewriting, that would take me quite some time. (Though, much
less then I needed up to now, as I now know where to find all the needed
changes.)

cheers
Boroondas
___
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] Product Backlog addition request: Build fixes for 64bit out-of-source

[Boroondas Gupte]

 On 08/26/2010 02:37 PM, Boroondas Gupte wrote:
> As some of you might know, I've been working on collecting patches and
> changesets on pJIRA and SVN that allow me to build
> lindenlab/viewer-development
>  with the settings
> above. I've applied them to my repository at
> http://bitbucket.org/boroondas/snowstorm-development , ported/modified
> them where necessary. I also had Techwolf port some of his own
> patches. (Available on his repo
> . Thanks Techwolf!)
>
> The final result, merged with the many changes that came from upstream
> meanwhile, can be found at the current tip (i.e. rev a0292ef8)
> 
> of my repository.
Yesterday, I had to realize that hg was using my graphical merge tool of
choice (meld ) differently than I expected
(and different from what |git mergetool| does with it)^[1 <#fn1>] . Thus
most merges where I manually resolved conflicts with meld are probably
faulty. If I'm lucky, only doc/contributions.txt is affected, but I'm
not sure.

To avoid others cloning the faulty merges and applying new commits ontop
of them, I've moved my repository to boroondas/snowstorm-development
DON'T USE THIS REPO! Faulty merges!
.
If you already have pulled or cloned from
bitbucket.org/boroondas/snowstorm-development before that, please
refrain to base any work on my merges or be prepared to having to rebase
it. I'll follow up with a new clone at the original location of my
repository soon and will hopefully get the merges right this time.
(KDiff3, with the proper configuration
, seems to augment hg better
than meld, but I'm still new to it so have to be careful.) While I'm at
it, I might also re-do some of the non-merge commits, so for now it
might be saver to base nothing on /any/ commits by me.

Sorry for the inconveniences and please bear with me as I learn all this
stuff.

As the Product Backlog inclusion is supposed to happen even before any
work on the issue is started, I hope it can move forward regardless.

Regards,
Boroondas


^[1 <#fn1back>] |HGMERGE=meld hg resolve --all| displays three text
fields side-by-side, from left to right: local, base, other. This seemed
very similar to |git mergetool| with meld, which has from left to right:
local, pre-merged, other.|| Thus I assumed that, as with |git mergetool|
with meld, the edited middle field would serve as the merge result, when
with hg, it actually  was the
edited local version in the left-most field. When one edits all 3 fields
in meld until they're equal and then saves them, this doesn't matter,
but I didn't do that in all cases.
___
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] Product Backlog addition request: Build fixes for 64bit out-of-source

[Boroondas Gupte]

 On 08/28/2010 11:48 AM, Boroondas Gupte wrote:
> I'll follow up with a new clone at the original location of my
> repository soon and will hopefully get the merges right this time.
http://bitbucket.org/boroondas/snowstorm-development/changeset/855c7fac6fc2
(and ancestors)

I re-did most commits with clearer indication in the commit messages of
how close they are to the original patches/SVN changesets, so don't pull
this into clones of the repository previously at
bitbucket.org/boroondas/snowstorm-development
.
If I don't get any vetos by the end of the week, I'll probably delete
the latter.

Again, testing and reviews of
http://bitbucket.org/boroondas/snowstorm-development most welcome!

Cheers,
Boroondas
___
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