[libvirt] [PATCH] keycodes: fix for 'make dist'

Nikolay Shirokovskiy nshirokovskiy at virtuozzo.com
Thu Aug 31 08:42:33 UTC 2017



On 31.08.2017 10:25, Michal Privoznik wrote:
> On 08/30/2017 01:19 PM, Nikolay Shirokovskiy wrote:
>> 'make dist' fails with error now:
>>
>> make[2]: Entering directory `/root/dev/libvirt/src'
>> make[2]: *** No rule to make target `linux', needed by `distdir'.  Stop
>>
>> It turns out that in am__libvirt_util_la_SOURCES_DIST variable KEYTABLES
>> is not expanded correctly. Like 'linux' stays 'linux' instead of util/virkeycodetable_linux.h.
>>
>> We do not need generated headers in distribution anyway and won't get
>> the error too.
>> ---
>>  src/Makefile.am | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/Makefile.am b/src/Makefile.am
>> index 0ed4331..94ca528 100644
>> --- a/src/Makefile.am
>> +++ b/src/Makefile.am
>> @@ -273,7 +273,6 @@ KEYMANS = $(KEYPODS:%.pod=%.7)
>>  
>>  man7_MANS = $(KEYMANS)
>>  
>> -UTIL_SOURCES += $(KEYTABLES)
>>  BUILT_SOURCES += $(KEYTABLES)
>>  MAINTAINERCLEANFILES += $(KEYTABLES)
>>  CLEANFILES += $(KEYMANS) $(KEYPODS)
>> @@ -1224,6 +1223,7 @@ libvirt_la_LIBADD = $(libvirt_la_BUILT_LIBADD)
>>  libvirt_la_BUILT_LIBADD = libvirt_util.la
>>  libvirt_util_la_SOURCES =					\
>>  		$(UTIL_SOURCES)
>> +nodist_libvirt_util_la_SOURCES = $(KEYTABLES)
>>  libvirt_util_la_CFLAGS = $(CAPNG_CFLAGS) $(YAJL_CFLAGS) $(LIBNL_CFLAGS) \
>>  		$(AM_CFLAGS) $(AUDIT_CFLAGS) $(DEVMAPPER_CFLAGS) \
>>  		$(DBUS_CFLAGS) $(LDEXP_LIBM) $(NUMACTL_CFLAGS)	\
>>
> 
> I'm sorry, but I'm failing to see this problem. Do you still see it with
> the current HEAD? Is it possible that the variable is a bashism and
> therefore doesn't work everywhere?
> 
> KEYCODES = linux osx atset1 atset2 atset3 xt xtkbd usb win32 rfb
> KEYNAMES = linux osx win32
> KEYTABLES = \
> 	$(KEYCODES:%=util/virkeycodetable_%.h) \
> 	$(KEYNAMES:%=util/virkeynametable_%.h) \
> 	$(NULL)
> 
> 
> Michal
> 

Hi, Michal. You are right, I was too hurry to send this patch. Actually
I have this problem on v3.6.0 with some downstream patches. I've checked build
on vanilla v.3.6.0 and upstream on my system and they are ok. So it is interference
from downstream patches. It is just not obvious how they caused such an error.

Nikolay




More information about the libvir-list mailing list