Re: [libvirt] [PATCH 0/2] First round of out-of-tree build fixes

On 11/11/19 2:42 PM, Daniel P. Berrangé wrote: > On Mon, Nov 11, 2019 at 02:22:19PM +0100, Michal Privoznik wrote: > > Some low hanging fruit here. > > > > 3) I've tried to update Gentoo live ebuild, but it failed to compile: > > > > Making all in src > > make[2]: Entering directory '/var/tmp/portage/app-emulation/libvirt-9999/work/libvirt-9999_build/src' > > ... > > /usr/bin/perl /var/tmp/portage/app-emulation/libvirt-9999/work/libvirt-9999/src/access/genpolkit.pl < /var/tmp/portage/app-emulation/libvirt-9999/work/libvirt-9999/src/access/viraccessperm.h > access/org.libvirt.api.policy || rm -f access/org.libvirt.api.policy > > /usr/bin/perl -w /var/tmp/portage/app-emulation/libvirt-9999/work/libvirt-9999/src/rpc/gendispatch.pl --mode=aclheader \ > > remote REMOTE /var/tmp/portage/app-emulation/libvirt-9999/work/libvirt-9999/src/remote/remote_protocol.x \ > > > access/viraccessapicheck.h > > /bin/sh: access/org.libvirt.api.policy: No such file or directory > > > > The libvirt-9999_build/src/access dir doesn't exist (I'm surprised it > > wasn't created automatically by autotools since src/ was). I'll have to > > investigate further. > > I hit this problem when making the RPM uses a build!=src dir > originally. I can't recall what I did to fix it though - it > was something annoyingly stupid though IIRC. Like a parallel > build happening when it shouldn't or something like that. I've identified the issue. It's ebuild/eclass who disables dependency-tracking whenever possible. Gentoo developers claim it's for faster configure (because by default, gentoo does in-tree builds) and they are right. But what dependency tracking has to do with creating directories is beyond me.