Re: Adding bibisect repository support to tinbuild2

So... I committed you patch, and then refactored it 'a bit'

First I separated the operation in 3 differents operations:

1/ the need to make the install: I added in Makefile.top a new
install-tb target that avoid the 'rebuilding' for nothing, and just do
 make dev-install (except that on linux it does not use the 'link to
solver' abilities, to not screw up the cp -R later)
That is done in do_make

TODO: right now we make install and deliver at every build... there
may be a reason to do that less often... but the logic to only
conditionally do that is not obvious. time based suck, since in 1
hours during european business day typically see 10 times more commit
than on the week-end for instance. so the best would probably, if one
does not want to deliver to bibisect at every iteration of the
buildbot, to somehow count the commit since the last deliver... (Note:
I only test PUSH_TO_BIBISECT_REPO == 0 or != 0 so that we could use
that variable value to indicate the number of commit in between
deliver)

Note: I presume that the bibisect repo as a branch that match the
branch we are building on in the source. we switch to that branch
before each build.
It is the responsibility of the buildbot maintainer to create new
branches as needed (it is not trivial to automatically find the right
branch point in bibisect)

2/ the need to 'deliver' the install to bibisect... that is done in post_make()

3/ the optional need to push to a remote bibisect repository.. that I
have disable so far. There I think some code to be written to control
when and how often this is done
that is done in do_push()
right now, git push manually  (or with a daily cron) will do the trick
Note that not everyone that construct a bibisect repo necessarely want
or can publish it to a remote repo

4/ I've added some sanity check in tinbuild2, to detect upfront if -x
is requested but ARTIFACTDIR is not set or is not a git repo (btw
ARTIFACTDIR _has_ to be defined in config/$profile.cfg, since there is
no good and safe default value for it (I accidentally ran the code
with a default ARTIFACTDIR on my Mac it would have eventually blown-up
my ramdisk and that could have taken a while before I noticed)

all that allow:
to keep tinbuild_phase.sh pretty lean and readable (lean is important
because tinbuild_phase.sh is no overridable on a per OS level, so the
more stuff it has the more likely that will become a problem, we want
to keep code in tinbuild_phases.sh fairly high-level and very unlikely
to suffer portability issue)
to keep individual function do essentially one thing and one thing
only (generate the install, copy the install to bibisect, push
bibisect)


Also: I tested it on Mac and it works just fine :-), next I'll try to
check on my Windows tinderbox.. It it works fine, I'll deploy it on
the ByteMark's windows tb.


FYI:
the order of sourcing of files is:
source tinbuild_internal.sh
source tinbuild_internal_<OS>.sh
source tinbuild_phases.sh
source ~/.tinbuild/config/$profile.cfg
source ~/.tinbuild/phases$profile.sh

so internal_<OS>.sh is meant for stuff that are OS dependant (to
override internal.sh)
but it cannot override phase.sh functions... overriding phase.sh or
overriding anything else due to machine specific need is done in
$profile.sh
(that is one way one can deal with ramdisk-base build for instance,
but it is flexible enough so that tinbuild2 user can tweak it the way
they want without the need to upstream stuff or dirtying their
buildbot repo)

I mention that because I notice that in your setup/test stand-alone
scripts(*) you are sourcing some of these and not in the intended
order.

Norbert

(*) which incidentally, I have not updated to reflect the changes in
tinbuild2, so they are broken now :-)