On 09/06/2013 02:22 PM, Eric Blake wrote:
> I'm playing with latest master branch (reports itself as version 1.99a;
> based on commit v1.14-120-gd26663f), and am seeing weird behavior
> regarding depcomps when trying to build libvirt commit 93e5997
> (http://libvirt.org/git/?p=libvirt.git;a=summary):
> 

>  986
> 
> Could this be caused by BUILT_SOURCES containing $(srcdir) in the name
> (because we intentionally want to generate the .c files into srcdir for
> the sake of tarballs built on systems with less-than-stellar rpcgen)?
> Is this a misuse of BUILT_SOURCES, where we should instead just have a
> rule to generate the files but not mark them as BUILT_SOURCES?  (I guess
> that means adding a dist-local hook to ensure the files are built, since
> that may have been _why_ libvirt was trying to abuse BUILT_SOURCES.)
> And is this a new issue, or just something that was latent in 1.13 and
> exposed because of 1.14+'s move to subdir-obj by default?

More info - I tried building the 1.14 tarball instead of bleeding-edge
master; and there, I got lots of warnings about not using
subdir-objects; after modifying configure.ac to add subdir-objects to
the AM_INIT_AUTOMAKE line, I can see the same behavior there.  So I'm
suspecting that this has either been a latent problem with
subdir-objects pre-dating 1.14, and/or a latent bug in libvirt's abuse
of BUILT_SOURCES, and not a recent regression (what made it trigger was
the fact that master has enabled subdir-objects by default).  Still,
even if I manage to fix the libvirt Makefile.am, I am keeping this bug
open, as I think automake should do a better job about flagging use of
literal '$(srcdir)' as an error rather than actually trying to create a
directory by that name.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org