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
Description: OpenPGP digital signature
--- End Message ---