[pkg-fgfs-crew] The w option is a bad idea

[Arnt Karlsen]

On Sat, 2 Mar 2013 00:08:44 -0500, Pat wrote in message 
<20130302000844.19b3146c at spinnaker>:

> The w option I proposed recently creates a new folder in which to
> build a  flightgear is a very bad idea.  Please do not publish it.  

..agreed.  We need a script that builds a complete local git service, 
so we can do our various "git branch foo ;git pull"'s etc from that,
and _then_ build the build trees we want.  A build tree server.

..I cc: Geoff too because his script should do likewise, IMO.

> If used as I originally intended, to create different builds, for
> example: one for master, one for stable and another for next, yet
> another for maint, that alone puts too much burden on gitorious. If
> you extend it to separate folders for diferent sets of parameters it
> get's totally out of hand.
> 
> A single new run of Download_and_Compile.sh, which downloads the
> entire project already violates gitorious terms of service
> (500MB/month). Imagine gitorious' quite appropriate reaction to one
> IP address doing several full downloads of fgdata.

..we can script fetching the bundle instead, and then update that,
like in http://wiki.flightgear.org/Building_Flightgear_-_Debian ,
but with either: cd $prefix
wget -c \
http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.10.0.tar.bz2
tar xjf FlightGear-data-2.10.0.tar.bz2  # etc ...

...or _the_ http://wiki.flightgear.org/Git#fgdata.bundle way, which
works for all git branches.

> What I need to come up with is a way to support simultaneous builds
> from a single set of flightear/simgear/OpenSceneGraph/openrti git
> clones that I already have in full on my hard drive.  There should be
> no reason to create duplicate clones directly from gitorious unless
> there is serious file corruption.
> 
> I've come up with several approaches:  

..you want _one_ script doing _everything_?  I now believe that is a 
bad idea.  I'm thinking the initial script should build the complete
local git service, complete with one script for each tree, and one
master script to run all the other tree scripts, and to pull updates
into the local git service.

..once we have this scheme up and going, we will no longer have these
current nuclear melt downs that scare people away, we will have a 
flyable working stable version and a few smoking piles of build tree
logs that squeals out bug where we try new idiot stunts.

..pushing work upstream can then be done from "public trees" feeding
our own github etc accounts so we no longer have to flog maintainers
into action to get new code tested, all it takes is a wee hint posted
in the mail lists or forums, advertizing the new idiot stunts so we
can easily set up local idiot stunt build trees, by pasting in that
idiot stunt url into a copy of a working build tree script and watch
the smoke.

..a dozen or so of short wee easily maintained scripts should do it.

..we want FlightGear developers, and I see no reason to scare them
away with the current pointless demand that they master 3 different 
code version tools just to keep track of FG code, and then ... etc,
when we can tell 'em to "Just try the script!".

..a script tarball is easily ported to the various distro package
formats, which again means the distros will add their own tweaks
to ease their own workload, while keeping _all_ FG versions handy 
for their own distro build services.

..come to think of it, I'll cc: Debian FlightGear Crew
<pkg-fgfs-crew at lists.alioth.debian.org> too.


> 1.  just clone the primary local clones as many times as needed
> directly on the local machine, without going back to gitorious.
> 2.  use the git script meant for this exact purpose.

..I ranted a wee bit this way, above. :o)

> 3.  Try setting GIT_DIR, and swapping the value of GIT_INDEX_FILE and
> GIT_WORK_TREE to do different builds.
> 4.  Try setting GIT_DIR and GIT_INDEX_FILE and swap the value of
> GIT_WORK_TREE to do different builds.
> 5.  Don't mess with git, just reset the version on a single git repo
> and do each build sequentially.
> 
> Each of these approaches has advantages
> and disadvantages. Some may not work.  I'm actually going to try each
> and see if I can adapt the results to download_and_compile.sh without
> breaking anything.

..you'll be a Nobel Prize Laureate if you manage that, 
meanwhile I'll go play with my chain saw. ;o)

> The only thing I know of that is broken is the build for fgviewer with
> the -i option.  I'm trying to figure this one out, but its beyond me.
> I've contacted Mathias on the issue to see if he has an opinion.

..I have both scripts buildng ok, but download_and_compile.sh built
fgfs bombs out the same "./fgfs: error while loading shared libraries:
libRTI-NG.so.1: cannot open shared object file: No such file or
directory" old tired way.  It works off Geoff's script, though.

> The first think I think we need is the capability of doing builds for
> just master and for maint.  The script already does a nice job on 
> master/next and stable.
> 
>  -Pat
> 
> git tricks I havent' tried yet:
> 
> Move a git repository from one folder to another.
> 
> Set values for GIT_DIR, GIT_INDEX_FILE and GIT_WORK_TREE 



-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.