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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#15293: closed (odd .deps directories being created)
Date: Mon, 21 Apr 2014 10:34:02 +0000

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

Your message dated Mon, 21 Apr 2014 11:33:27 +0100
with message-id <5354F3F7.9070308 <at> gmail.com>
and subject line Re: bug#16375: subdir-objects breaks build which specifies sources relative to $(top_srcdir)
has caused the debbugs.gnu.org bug report #15293,
regarding odd .deps directories being created
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
15293: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15293
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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 3 (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 part 5 (message/rfc822, inline)]

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.