[opensource-dev] Commandline Development Environment for multiple viewers for linux developers

[Aleric Inglewood]

The true "engine" here (cdeh) doesn't do anything viewer specific at all.
It just switches command history if you change directory (to one where
you told it that you want to have a different command history) and more
importantly in this case, it sources 'env.source' files when it encounters
them.

Hence, you are free to change the env.source files to your liking to
do what you want. The files that I gave are just what *I* use.

On Mon, Jul 12, 2010 at 7:08 PM, Henri Beauchamp <sldev at free.fr> wrote:

> On Mon, 12 Jul 2010 14:32:07 +0200, Aleric Inglewood wrote:
>
> > Hi, I just created a new wiki page
> >
> >
> https://wiki.secondlife.com/wiki/Development_Environment_for_Multiple_Viewers
> > that I'd like to bring under the attention of all linux developers.
>
> One remark is about the strange use of the -p0 option for the patches...
> Unified diffs (patches) are most usually produced with a command such as:
> diff -urN original_source_tree/ patched_source_tree/ >resulting_patch.diff
> which produces patches to apply with 'patch -p1' from inside the source
> tree
> directory to patch (and AFAIK this method applies for pretty much all Linux
> packaging systems).
>

It was just my choice. You can change env.viewers and make it use -p1
diffs everywhere. The reason I chose -p0 is because 'svn diff' produces
-p0 diffs. If you want to switch to -p1 at all times then you'd need to find
a way to make 'svn diff' produce -p1 diffs, I'm not sure that is possible.

> Although things might look scary at first and not work out-of-the box at
> first, I garantee that using this system will increase your productivity
> a lot on the long run. It's worth to put time into.

 I got my own productivity tool which, as a bonus, allows to build and link
> the viewer against a mixed set of libraries (system libs for the most
> common
>

Not sure I see the 'bonus' part, since, by editting env.viewers, you can
make
this do whatever linux is able to provide (everything).

Most notably, I already added full support for CXXFLAGS and LDFLAGS,
examples of which are in env.viewers. I have libraries installed all over
the place in "random" places*) and have no problems compiling and linking
against them. *) That is, /usr/src/secondlife/libraryname/lots/more and
some are installed with prefix /sl, so /sl/lib and /sl/usr/lib.


> libs, and LL's provided ones for exotic or Linden-patched libs), something
> the viewer build system normally doesn't allow/isn't designed for.
> It involves typing a simple command, e.g.:
> cmake-SL /opt/SecondLife/12350
> (with all sources, libs, archive tarballs/zips and patches (-p1 ones) held
> in /opt/SecondLife/12350, here for viewer v1.23.5).
>
> I also use it to prepare the sources for later compilation under Windows,
> (e.g.: cmake-SL /opt/SecondLife/12350 --prep).
>
> This tool has been reused and adapted by some third parties viewer
> developpers and you can therefore find it in several flavours (including
> some allowing to retreive the source tree from svn repositories). Feel
> free to reuse part of it for your own script.
>
> My original versions are available here:
>
> - for v1.19 and earlier viewers:
>
> https://wiki.secondlife.com/wiki/User:Henri_Beauchamp/Automated_Linux_Build_Script_(1.20_and_earlier)<https://wiki.secondlife.com/wiki/User:Henri_Beauchamp/Automated_Linux_Build_Script_%281.20_and_earlier%29>
>
> - for v1.20 and later viewers (including Snowglobe):
>
> https://wiki.secondlife.com/wiki/User:Henri_Beauchamp/Building_the_viewer_with_CMake/cmake-SL_script
>
> Note that I didn't test cmake-SL with Snowglobe 2.x (that viewer is simply
> too much of a repellent because of its *unusable*, dumbified UI), but it
> should work too with it (even if more options could be added in cmake-SL
> to take into account the new libraries in Snowglobe such as qtwebkit and
> stuff).
>
> Henri.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100712/6f74b9a0/attachment.htm