GNU bug report logs - #15293
odd .deps directories being created

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15293 in the body.
You can then email your comments to 15293 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: bug-automake <at> gnu.org
Subject: odd .deps directories being created
Date: Fri, 06 Sep 2013 14:22:36 -0600

[Message part 1 (text/plain, inline)]

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):

$ find -name .deps -exec rm -r {} +
$ ./config.status > /dev/null
$ find -name .deps
...
./src/phyp/.deps
./src/$(srcdir)/remote/.deps
./src/$(srcdir)/access/.deps
./src/$(srcdir)/lxc/.deps
./src/$(srcdir)/locking/.deps
./src/util/.deps
...

Huh?  What are those literal directories named '$(srcdir)' doing in my tree?

$ make
...
make[2]: Entering directory `/home/eblake/libvirt-tmp2/src'
Makefile:4992: warning: overriding recipe for target `access/.dirstamp'
Makefile:4978: warning: ignoring old recipe for target `access/.dirstamp'
...
Makefile:4966: warning: ignoring old recipe for target
`locking/.deps/.dirstamp'
Makefile:5904:
access/.deps/libvirt_driver_access_la-viraccessapicheck.Plo: No such
file or directory
Makefile:5905:
access/.deps/libvirt_driver_access_la-viraccessapichecklxc.Plo: No such
file or directory
...
Makefile:5913:
remote/.deps/libvirt_driver_remote_la-remote_protocol.Plo: No such file
or directory
make[2]: *** No rule to make target
`remote/.deps/libvirt_driver_remote_la-remote_protocol.Plo'.  Stop.

The file reported missing exists, if you look in the odd directory name:

$ ls src/\$\(srcdir\)/remote/.deps/
libvirt_driver_remote_la-lxc_protocol.Plo
libvirt_driver_remote_la-qemu_protocol.Plo
libvirt_driver_remote_la-remote_protocol.Plo

Obviously, the bogus directory names for .deps has caused the rest of
the build process to be hosed.  But I'm not sure where it is going
wrong, and whether the bug is in bleeding-edge automake or in my
Makefile.am.  I'm not sure how to quickly narrow in on a smaller test
case from the Makefile.am in question
(http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/Makefile.am;h=ca35e04).
 But looking for some of the strings in question, I see:

 303 # The remote RPC driver, covering domains, storage, networks, etc
 304 REMOTE_DRIVER_GENERATED = \
 305                 $(srcdir)/remote/remote_protocol.c              \

 335 REMOTE_DRIVER_SOURCES =                                         \
 336                 gnutls_1_0_compat.h                             \
 337                 remote/remote_driver.c remote/remote_driver.h   \
 338                 $(REMOTE_DRIVER_GENERATED)

 983 libvirt_driver_remote_la_SOURCES = $(REMOTE_DRIVER_SOURCES)
 984
 985 BUILT_SOURCES += $(REMOTE_DRIVER_GENERATED)
 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?

Does the documentation on BUILT_SOURCES need to be expanded to describe
what is proper (or invalid) relations between generated source files and
files shipped in the tarball, where it is desired that the end user need
not regenerate the file, but a developer building from git always keeps
the file up-to-date without having to check it into git?

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

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 15293 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
Cc: 15293 <at> debbugs.gnu.org
Subject: Re: bug#15293: odd .deps directories being created
Date: Fri, 06 Sep 2013 14:40:43 -0600

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 15293 <at> debbugs.gnu.org (full text, mbox):

From: Bert Wesarg <bert.wesarg <at> googlemail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15293 <at> debbugs.gnu.org
Subject: Re: bug#15293: odd .deps directories being created
Date: Sat, 7 Sep 2013 18:21:51 +0200

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 <eblake <at> 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
>

Message #16 received at 15293-done <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Diab Jerius <djerius <at> cfa.harvard.edu>
Cc: 13928 <at> debbugs.gnu.org
Subject: Re: bug#16375: subdir-objects breaks build which specifies sources
 relative to $(top_srcdir)
Date: Mon, 21 Apr 2014 11:33:27 +0100

[+cc 13928 <at> debbugs.gnu.org]

References:
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16375
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15919
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15293

Known bugs sadly -- all duplicates of http://debbugs.gnu.org/13928

See also recent thread on the automake list (with sad updates
regarding the current Automake development status):
http://lists.gnu.org/archive/html/automake/2014-04/msg00002.html

Closing these bug as a duplicate.  Feel free to continue the
discussion in the http://debbugs.gnu.org/13928 thread.  And
if anyone manages to come up with a patch, I will certainly
make time to review it.

Thanks, and sorry for the lack of progress,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.