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

[Jaroslav Suchanek]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180222/b71ad014/attachment-0001.sig>