Re: [libvirt] [PATCH] build: Fix build with old automake

On 03/18/2014 05:00 AM, Jiri Denemark wrote: That would be VPATH rewriting at play. Does $(builddir)/cpu/cpu_map.xml fare any better? $(srcdir) is not the problem - that part of the rule can be written absolute as follows: $(AM_V_GEN)ln -s `cd $(srcdir) && pwd`/cpu/cpu_map.xml $@ It's just the $(abs_builddir) we're trying to figure out if we can avoid. I looked at gnulib for inspiration, because it also does a symlink of GNUmakefile when doing a VPATH build while using the original file when doing in-tree. But it was depressing: it doesn't work for VPATH builds on RHEL 5: configure.ac: # Autoconf 2.61a.99 and earlier don't support linking a file only # in VPATH builds. But since GNUmakefile is for maintainer use # only, it does not matter if we skip the link with older autoconf. # Automake 1.10.1 and earlier try to remove GNUmakefile in non-VPATH # builds, so use a shell variable to bypass this. GNUmakefile=GNUmakefile m4_if(m4_version_compare([2.61a.100], m4_defn([m4_PACKAGE_VERSION])), [1], [], [AC_CONFIG_LINKS([$GNUmakefile:$GNUmakefile], [], [GNUmakefile=$GNUmakefile])]) Makefile.am: distclean-local: clean-GNUmakefile clean-GNUmakefile: test '$(srcdir)' = . || rm -f $(top_builddir)/GNUmakefile But maybe that's some food for thought - instead of having a rule that uses a direct file name, perhaps you can instead have a witness rule on a stamp file name, where we write the link ourselves when needed, and then have all dependencies be on the stamp (which will ALWAYS exist only in builddir): cpu/cpu_map.xml.stamp: $(AM_V_GEN)if test -f cpu/cpu_map.xml; then \ :; else \ ln -s `cd $(srcdir) && pwd`/cpu/cpu_map.xml \ cpu/cpu_map.xml; \ fi && touch $@ -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org