On Sun, May 26, 2013 at 6:24 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Sun, May 26, 2013 at 06:20:17PM +0000, Blue Swirl wrote: >> On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote: >> >> On 26 May 2013 13:31, Michael S. Tsirkin <m...@redhat.com> wrote: >> >> > On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: >> >> >> I definitely think individual project makefiles are the wrong place >> >> >> to fix this. If create-as-temp-and-rename is useful functionality >> >> >> it needs to go in the compiler so that everybody benefits. >> >> > >> >> > This will not help users on existing systems. >> >> > Also it's not just compiler. We'd have to do it in linker, >> >> > asm, ... lots of work. >> >> >> >> This is clearly less work than implementing it in the makefile >> >> of every single open source project in the world (or even every >> >> single open source project in Debian). >> > >> > You seem to have removed the part that explained that >> > 1. we run scripts in our makefiles so need to handle that anyway >> > 2. we care about users on existing systems >> >> A generic hook (default none, or maybe "test -s") after object >> production and before linkage should be enough but would scale to SHA >> producing/verifying tools. >> >> > >> > This means that we would need the fix in our makefiles even >> > if compiler and linker gain this feature. >> >> Depends on the feature. If the object files have robust checksums >> which are checked after output and before input, this should be >> transparent to the build system. >> >> > >> >> > You are wellcome to implement this in compiler/linker/etc if you like >> >> > but we will still want to handle it in our makefile as well. >> >> >> >> I specifically don't want it handled in our makefiles because >> >> it's the wrong place to fix the problem and it will make >> >> our build system more complicated. >> >> +1 >> >> Also, what is the worst case scenario? The link fails and you have to >> clean up and rebuild? An automated build system can't produce the >> expected output if the build machine is unreliable? > > It's a simple issue. > Each time I reboot during build, I have to make clean and rebuild. > This wastes my time so I looked for ways to save the time.
Compile under a stable kernel and test the bleeding edge kernel only as KVM guest? Get a different box for testing or compiling? Run 'sync' every time gcc finishes? Don't you have bigger problems with file systems due to the crashes? > On my system at least, it has no measureable cost, > likely also because size only looks at headers and metadata. For example on OpenBSD, 'size' does not seem to come from binutils, so there could be portability issues. > > If others are not interested, I can keep it out of tree. I've had problems with disk close to full, so I'm semi-interested if the solution does not slow down others and it's not too ugly. > >> >> >> >> -- PMM >> > >> >