On 22.02.2018 14:29, Daniel P. Berrangé wrote: > 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 > This would exactly fit my environment, I wouldn't even have to change the directory name :). This is prone to cause some confusion though, as it's changing the default behavior of bootstrapping. Maybe prompt the user in autogen.sh whether she/he wants to use a build directory (default=YES)? On the other hand I'm also used to run make check, which should also uncover VPATH issues. -- Regards, Viktor Mihajlovski -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
