Stephen Kelly said: > I wonder if it's possible for the CI system to maintain and clone > a working master build which patches could be applied to and build > incrementally? (an un-clean build) >
Andreas said: > How about investigating incremental builds? Could reduce compile time > to just a few minutes per patch. We do that where I work, with hundreds > of changes done to the repo every day, and every single patch is > compiletested. Tests are also run per change, but we only run fast > tests per change; slow tests are run in a separate cycle (on a best > effort basis). > > The occasional breakage happens whenever changes are made to build > files, like Makefiles or pro files, typically when moving code around. > But it's rare and manageable, as long as it's possible to force a full > rebuild on demand. I don't think it is a good idea. Having errors with incremental builds which go away when you do a clean build is one thing, but there are also some issues which _should_ cause the build to fail, but don't if you only do incremental builds. For example, if you make a change which causes some library or header to be removed/renamed, and you forget to update all consumers of that library/header, it can easily go unnoticed, because the old library/header still exists in the build tree until you do a clean build. Another example is failing to declare the dependencies between projects, which would typically be discovered by a clean build with high -j, but missed in incremental builds (because the dependencies are probably still there from the last build). I can't comment exactly how rare or not that would be for Qt. I guess it would happen more often during the most critical times and cause frustration when everyone is trying to get their refactoring integrated before some freeze. Anyway, I am not really interested in hitting the "do a clean build" button or attempting to determine/communicate the heuristics for deciding to do that. I would prefer us to move towards the state where, if the CI system posts a failure report onto your change, then there is a very high chance the failure is actually caused by your change. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development