Adding bibisect repository support to tinbuild2

[Michael Stahl]

On 25/07/12 22:01, Norbert Thiebaud wrote:
> On Wed, Jul 25, 2012 at 2:47 PM, Michael Stahl <mstahl at redhat.com> wrote:
>> On 21/07/12 23:12, Norbert Thiebaud wrote:
>>> 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)
>>
>> is a new make target substantially duplicating an existing one really
>> necessary?  there is a configure option --disable-linkoo to have a
>> solver installation without symlinks, couldn't the tinderboxes that do
>> bibisect just set that?
> 
> 1/ this step is purely for the mechanic of the tinderbox it is not
> intended to test any thing specific... so the less susceptible the
> tinderboxes are to the whim of the day, the better.
> 2/ I think the cost to not to high to keep the tb setup 'simple'...
> iow a 'it just just work'. the way it is now, all you have to do to
> start a bibisect repo is to create an empty repo, create a dummy
> commit, set the ARTIFACTDIR variable in the config file of the tb and
> use -x when running it. I prefer to avoid depending on configure
> option that may or may not be there tomorrow , that may or may not
> mean the same thing tomorrow, as much as I can.
> 3/ all that being said... if you feel strongly about it I can learn to
> live with --disable-linkoo

the problem with the duplication is that the next time somebody fixes a
problem with the "dev-install" target they will probably forget to fix
the "install-tb" target as well, and if the problem affects tinderboxes
as well then they will remain broken.  whether that is more likely, or
whether a change to --disable-linkoo is more likely, is of course
speculative.