On Mon, Jul 29, 2013 at 04:48:20PM +1000, Stephen Rothwell wrote: > On Mon, 29 Jul 2013 07:40:28 +0100 Mark Brown <broonie@xxxxxxxxxx> wrote: > > Yeah, unfortunately those issues are a good proportion of what gets > > caught by this sort of testing that wouldn't get caught in normal > > development so it doesn't seem worth doing something that won't at least > > give a linking kernel. > The problem is that you are impacting on other people's testing. Even if > this stuff builds for me, it may well break for people using other > arches/configs. These changes (adding dependencies on > CONFIG_COMPILE_TEST for devices that are currently only built for > particular platforms) are adding very little, but impacting on my time (at > least). I agree - what I'm saying here is that one of the biggest risks I'm expecting is something that fails to link so testing that doesn't generate at least a linked kernel isn't adequate coverage. Just testing that individual files build (as you were suggesting) isn't enough for me to be happy that the testing is doing enough to stop people running into these things. The additional coverage is really useful for anyone working at a subsystem level, it makes it much easier for them to do more comprehensive build testing on their work without having to install odd compilers or do quite so many builds. Missing things there has been a frequent source of problems in the past, and one that tends to be more painful overall than these issues since it tends to take longer to be discovered than anything found due to active build coverage testing and found by a different kind of user.
Attachment:
signature.asc
Description: Digital signature
