Re: next nightly build problem

[<don...@is...>]

Bruno Haible writes:
 > Depends on what you want to do.
 > 
 > - The set of builds that failed gives you an understanding which features
 >   caused regressions. In this case it's evident: forcing HEAPCODES worked,
 >   forcing TYPECODES worked, but the default choice did not work.
 > 
 > - If you are interested in continuous integration, you may want to
 >   set up build scripts that use 'multibuild-porting64-gcc' and
 >   signal regressions in any of the build configurations. This would
 >   be useful for Sam and me.

ok, that seems worth while.
At the moment I'm only running nightly builds on one linux machine,
a recent fedora.  Would it be useful to run on other recent linux
distributions?  I'm guessing a very old one would be less useful.

 > - If you are interested in a build that works, choose one of those with a
 >   large cbcstep3.log.

I'm hoping before long they'll all work.

 > - If you want to know about the performance: Since "make check" runs the
 >   benchmarks, in particular, the log file contains the benchmark results.
 >   You can compare them:

This had also occurred to me.
Does that enter into the default choice?
What is the current default (and why)?

One other thing:
When I get software updates will the local patch be undone?
If not, I really should undo it, right?  
Just guessing, would that be done like this?
  hg diff -c d61ff18e7daa | patch -p1

I'm hoping that patch will also be fixed before too long?