Re: [libvirt] RFC: should we mandate use of VPATH builds ?

One of the things we (well I) constantly screw up is VPATH builds. I've always tended to just build in the source tree, and as a result I'll often miss changes which break VPATH builds. Now our Jenkins CI catches this because it does VPATH builds only, so we don't bit-rot for very long. Unfortunately Travis CI does source tree builds only so I don't notice my mistakes when I test branches on Travis before pushing. I'll fix Travis to do VPATH builds too, but.... I notice that most modern build systems will refuse to ever do in source tree builds. eg Ninja/Meson/Perl/Python/Go/etc all put build artifacts in a separate directory from source. We could if we wanted to simply put a check right at the start of the configure.ac script to reject any attempt at doing a source tree build to force VPATH builds. This would mean we only ever have to care about one execution path instead of two execution paths. We could even make it such that autogen.sh will actually create a subdir "build" and change into it automatically before running configure, to help devs do the "right thing" by default. Essentially we're talking the difference between Today: - Source tree build ./autogen.sh && make - VPATH build mkdir build && cd build && ../autogen.sh && make Possible future - Source tree build No. - VPATH build ./autogen.sh && cd build && make Any opinions ? Do people really like source tree builds, or are they (like me) just doing them because its the easy/lazy option ? Regards, Daniel