On 20/12/17 12:48, James Greenhalgh wrote: > On Wed, Dec 20, 2017 at 10:02:45AM +0000, Paulo Matos wrote: >> >> >> On 20/12/17 10:51, Christophe Lyon wrote: >>> >>> The recent fix changed the Makefile and configure script in libatomic. >>> I guess that if your incremental builds does not run configure, it's >>> still using old Makefiles, and old options. >>> >>> >> You're right. I guess incremental builds should always call configure, >> just in case. > > For my personal bisect scripts I try an incremental build, with a > full rebuild as a fallback on failure. > > That gives me the benefits of an incremental build most of the time (I > don't have stats on how often) with an automated approach to keeping things > going where there are issues. > > Note that there are rare cases where depencies are missed in the toolchain > and an incremental build will give you a toolchain with undefined > behaviour, as one compilation unit takes a new definition of a > struct/interface and the other sits on an outdated compile from the > previous build. > > I don't have a good way to detect these. >
That's definitely a shortcoming of incremental builds. Unfortunately we cannot cope with full builds for each commit (even for incremental builds we'll need an alternative soon). So I will implement the same strategy of full build if incremental fails, I think. With respect with regards to incremental builds with undefined behaviour that probably means that dependencies are incorrectly calculated. It would be great to sort these out. If we could detect that there are issues with the incremental build we could then try to understand which dependencies were not properly calculated. Just a guess, however implementing this might take awhile and would obviously need a lot more resources than we have available now. -- Paulo Matos
