[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15293: odd .deps directories being created

From: Eric Blake
Subject: bug#15293: odd .deps directories being created
Date: Fri, 06 Sep 2013 14:22:36 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

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

$ find -name .deps -exec rm -r {} +
$ ./config.status > /dev/null
$ find -name .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
access/.deps/libvirt_driver_access_la-viraccessapicheck.Plo: No such
file or directory
access/.deps/libvirt_driver_access_la-viraccessapichecklxc.Plo: No such
file or directory
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/

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
 But looking for some of the strings in question, I see:

 303 # The remote RPC driver, covering domains, storage, networks, etc
 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)

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]