On 11/09/2015 02:30 PM, Trevor Saunders wrote:
So in general when I've done cross target things I think I've found more
bugs with config-list.mk than with a regtest, but the regtest has found
some things I think.
I'm finding config-list.mk fairly reliable, with the notable exception
of the avr-rtems issue and interix. But that may simply be function of
running it regularly.
However I actually don't mind bootstrapping and regtesting that much,
its more or less a few hours for the control and then another few for
each patch.
I usually save my results and only go back for a control build if
something goes wrong. Of course I'm usually stepping forward at least
once a day, so the number of new tests is usually manageable and allows
me to compare the first run of the day with the last run of the prior day.
On the other hand config-list.mk takes on the order of 12
hours, and setting up a cross for a quick test isn't really that quick.
Which means that if you have a patch touching a number of targets you
end up not checking it compiles at all until you run config-list.mk, and
then its a heavy weight operation.
FWIW, If we know what ports a particular patch would hit, I'd fully
support folks doing builds that didn't hit all of config-list.mk.
In case it's not obvious I do hope that we'll get to a point where the
class of bugs like "X is unused on port PDQ because it defines/does not
define FROBIT" just go away and we can get good first level coverage
with a native and perhaps a very small number of crosses (instead of the
200+ in config-list.mk now).
At some point I also want to see config-list.mk extended to do things
like "build the crosses and run test tree-ssa/ssa-dom-thread-11.c on all
of them". I've got hacks to do that locally, but they're strictly
hacks. I think this selectively deeper testing will become more
important as we put the first level coverage behind us.
So at least for the way I work I'd really rather write series that I can
incrementally test on just one target and be reasonably confident they
won't break other targets.
That generally works for me.
The add default macro definitions then wrap those with hooks, then
target by target replace the macro by hook overrides approach seems to
provide that you can incrementally test and fiind most of the issues,
but the change a macro every where approach doesn't really.
I think Bernd and I just have different approaches, preferences and
priorities on some stuff which results in slightly different priorities
or approaches to certain issues.
I've known Bernd a long time and will say he's very reasonable and his
concerns/objections are well thought out and carry a ton of weight with me.
Jeff
