On Mon, Nov 09, 2015 at 03:07:21PM -0700, Jeff Law wrote: > 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.
yeah, its reliable although I tend to find needing to have an installed trunk compiler a little painful. What I meant was that sometimes I've made mistakes and introduced testsuite failures or the like. > > > >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. SO my usual mode is to build up a branch just checking that a default build works, and then at the end run a script that regtests all the patches. That can suffer from intermitant tests, but its low human input so I like it. > 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. sure > 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. yeah, I'd actually like to see config-list.mk become part of the "real" build system at some point and you could do something like ./configure --target=i686-linux-gnu,ppc64-linux-gnu,alpha-dec-vms and stuff. > >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. Sure, we're all different ;) > 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. I don't really know him, but I don't really disagree with where he wants to get to. However I think we work fairly different ways, and review things differently. When I review patches (mostly for stuff more directly related to Mozilla my standards are basically it needs to be an improvement, and it needs to not introduce bugs. So I find the it might improve things, but it doesn't also accomplish X to berather odd, and hard to work with if I think getting directly to X might be hard. Trev > > Jeff
