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

[Eric Blake]

On 03/18/2014 05:00 AM, Jiri Denemark wrote:

>> Why don't we just avoid the whole issue by removing use of abs_srcdir
>> and abs_builddir.  Can this rule:
>>
>> $(abs_builddir)/cpu/cpu_map.xml:
>>         $(AM_V_GEN)ln -s $(abs_srcdir)/cpu/cpu_map.xml $@
>>
>> be just changed to
>>
>> cpu/cpu_map.xml:
>>         $(AM_V_GEN)ln -s $(srcdir)/cpu/cpu_map.xml $@
> 
> That's what I tried first but it does not work at all. I don't
> understand why but make thinks cpu/cpu_map.xml target is uptodate even
> though the file does not exist in builddir.

That would be VPATH rewriting at play.  Does $(builddir)/cpu/cpu_map.xml
fare any better?

> And $(srcdir) doesn't work
> for relative VPATH. For example, if VPATH is .., then
> 
>     abs_srcdir = /some/path/src
>     abs_builddir = /some/path/build/src
>     srcdir = ../../src
> 
> and the /some/path/build/src/cpu/cpu_map.xml link will be
> ../../src/cpu/cpu_map.xml and thus will point to itself.

$(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.

> And we can't
> just blindly do
> 
>     ln -s ../$(srcdir)/cpu/cpu_map.xml $@
> 
> because this would not work for absolute VPATH, when srcdir is
> /some/path/src.
> 
> Yeah, it's a mess.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140318/91dda3ae/attachment-0001.sig>