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

Re: [PATCH] tests/vpci: install test


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 10 Mar 2023 15:32:41 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lEy9u2qwxi3E/Tz+DV+Tf1MaPdOjXBFDw3HxTsKlYVk=; b=mb9EmrdfjcH1mZ32xBQS9qzWwLJ0gO3aegaCAy9r+6FLkWr7OEFELcBFtFqAl2jFTVcgXeWXJ/Tg34i2aCaF/rMvxqB3oKWHejbBwUbZfjHwpfe5kUjyAY8jR0zXScnqcfmWEhx9x/0UVt0vkL19eJAhvC/kMjqP70PWyOm7PP4vnbQpMEr7/0KzL4x/H840Wn77fT1TbBMo/6wesMVBQ1Ncl9pRXSv9hB4oOEsOq17w/R4oAS1fTG5fT9wPhAvc/N+myFx0t6QqMswejPvisORl9Lm/D0vuvBYFhiVelNuDmsLup02aSDRsRKpOtlgUDfqA7KJBCMWuiZ06ejJvNQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AkHjx+WX7Y0QwPec8wyNVdUC20L4rYCZ6KY1Zb2fdtW2WFnwFffyikHTOzGZFwXJM1YctPsoVsqw/PaBjGzuSnOOnZFswii+tVOu8/1su4j2/AExMh7GtH5JYE1Q0fbIbgPElWtl7t4+b1GoZcXrQ6KWSsiJ43WfhjAUzqrvyPQth1hwgKS31yyzKBoXsqqDT7GM6pJBV7VU610ynK7RM7VnntvQAsB+il2bWUEZDb43M3/Hmn4VxLnRK/kcSoxUQVR7n+I2G/MehVXi6Uua+1UFHWheoKDLuYRjLK7IJXRrGvD7E2zMbYi6t+Jkvftyfa4O8yZhqESu5EkF3uqUww==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: andrew.cooper3@xxxxxxxxxx, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 10 Mar 2023 14:33:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.03.2023 14:38, Roger Pau Monné wrote:
> On Fri, Mar 10, 2023 at 12:06:29PM +0100, Jan Beulich wrote:
>> On 09.03.2023 17:58, Roger Pau Monne wrote:
>>> Introduce an install target, like it's used by other tests.  This
>>> allows running the test on the installed systems, which is easier than
>>> running it during the build phase when dealing with automated testing.
>>> Strictly speaking the vpci test doesn't require to be run on a Xen
>>> host currently, but that allows easier integration with logic that
>>> runs the rest of the tests.
>>
>> I accept that as a possible way of looking at things, but personally I
>> remain unconvinced of this model. To me what is installed should be of
>> value to users. If there was a properly separated directory where all
>> (and only) tests were put, I might agree with installing. (Nevertheless
>> this isn't an objection, merely a remark.)
>>
>>> While there also adjust the makefile to use $(RM), and rename the
>>> resulting binary to use a dash instead of an underscore (again to
>>> match the rest of the tests).
>>>
>>> Since the resulting test binary is now part of the distribution CC
>>> must be used instead of HOSTCC.
>>
>> This breaks the run: goal, doesn't it? If the new mode is wanted, I
>> think the two kinds of binaries (and rules) need separating (maybe a
>> way can be found to avoid duplicating the rules, which would seem
>> desirable).
> 
> The run rule is not hooked up in any of the upper level makefile logic,

What about the run-tests-% goal in the top level Makefile?

> so I think it's usage (like in other tests that also use CC and have
> such rule) is left to callers that know that HOSTCC == CC.
> 
>>> --- a/tools/tests/vpci/Makefile
>>> +++ b/tools/tests/vpci/Makefile
>>> @@ -1,7 +1,7 @@
>>>  XEN_ROOT=$(CURDIR)/../../..
>>>  include $(XEN_ROOT)/tools/Rules.mk
>>>  
>>> -TARGET := test_vpci
>>> +TARGET := test-vpci
>>>  
>>>  .PHONY: all
>>>  all: $(TARGET)
>>> @@ -11,17 +11,23 @@ run: $(TARGET)
>>>     ./$(TARGET)
>>>  
>>>  $(TARGET): vpci.c vpci.h list.h main.c emul.h
>>> -   $(HOSTCC) -g -o $@ vpci.c main.c
>>> +   $(CC) -o $@ vpci.c main.c
>>
>> You're losing -g and you're also not covering for it by adding $(CFLAGS)
>> (there should have been use of $(HOSTCFLAGS) already before, I suppose).
> 
> Wasn't sure whether I should add CFLAGS and LDFLAGS here, I guess
> LDFLAGS is really not needed because the test is not linked against
> any library, but could be added just in case.

Perhaps. I find $(LDFLAGS) odd to use anyway - by its name it ought to be
passed to $(LD), not $(CC).

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.