Hi, this seems a duplicate of to http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928.
On Fri, Sep 6, 2013 at 10:40 PM, Eric Blake <ebl...@redhat.com> wrote: > 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 >
