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