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 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 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


 - Source tree build

    ./ && make

 - VPATH build

    mkdir build && cd build && ../ && make

Possible future

 - Source tree build


 - VPATH build

    ./ && 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 ?

|:      -o- :|
|:         -o-   :|
|:    -o- :|

libvir-list mailing list

Reply via email to