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

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

 



On Tue, Mar 18, 2014 at 06:27:48 -0600, Eric Blake wrote:
> 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?

No, that doesn't work either.

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

OK, this seems to work. It's uglier and doesn't regenerate the link if
someone removes it (the *.stamp file would need to be removed too) but
if that's considered a better way compared to setting abs_*dir, I can
make a proper patch out of it after testing it in all situations.

Jirka

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]