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 <sl...@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. >
_______________________________________________ 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
