bug#15293: odd .deps directories being created

[Bert Wesarg]

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 <address@hidden> 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
>