[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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Feb 22, 2018 at 13:29:35 +0000, Daniel Berrange 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.
I vote for _no_. I mostly use in-tree builds except for when messing with makefiles. I think the situation is similar to making contributors running syntax-check. We document it in multiple places that patches should pass it yet we get patches that fail it all the time.
On Thu, Feb 22, 2018 at 13:29:35 +0000, 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 think most Linux distributions build their packages in tree and also ./configure && make && make install is the well known way of building software. I don't think we should break it.
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.
I don't this is a good idea. It would make using other directory than ./build harder and it won't help developers much anyway since they will need to change all their paths to the built binaries they want to execute. Jirka
On Thu, Feb 22, 2018 at 01:29:35PM +0000, 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 ?
I like the idea of VPATH builds as usually it should be possible to build one shared source tree on different OSs. But since some files in libvirt are still generated into the source tree this is not fully supported. On the other hand it does not feel right to mandate it. Thanks, J.
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
participants (5)
-
Daniel P. Berrangé -
Jaroslav Suchanek -
Jiri Denemark -
Peter Krempa -
Viktor Mihajlovski