From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Ian Jackson" <iwj@xenproject.org>, "Wei Liu" <wl@xen.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Juergen Gross" <jgross@suse.com>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 0/5] tools/tests: More cleanup for automation improvements
Date: Wed, 16 Jun 2021 08:38:48 +0200 [thread overview]
Message-ID: <5b0de61c-0276-cf06-4eeb-cda9ca990940@suse.com> (raw)
In-Reply-To: <20210615161905.9831-1-andrew.cooper3@citrix.com>
On 15.06.2021 18:19, Andrew Cooper wrote:
> Jan/Roger: x86_emulator and vpci use $(HOSTCC) not $(CC). While they are unit
> tests, we still potentially want to run them in dom0 rather than the build
> environment - particularly for x86_emulator which is heavily CPUID based and
> wants to run on a wide set of hardware. Any issues moving them off $(HOSTCC)?
Well, yes, I'm afraid: If anything, we may need to build two binaries,
or build the one binary two different ways: The "run" (and "run32" for
the emulator harness) target wants a binary built with HOSTCC. The
install target (which prior to your series does nothing) indeed wants
building with CC. So maybe we want something like
install: HOSTCC:=$(CC)
plus suitable detection of whether the opposite set of objects are
presently in the build area, requiring a full rebuild? (Of course this
will work only as long as HOSTCC isn't used for any build time helper
binaries. See "x86emul: test AMX insns" for when this starts not to be
the case anymore for the emulator harness. So we'd need yet another
variable to express this detail.)
Jan
next prev parent reply other threads:[~2021-06-16 6:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-15 16:19 [PATCH 0/5] tools/tests: More cleanup for automation improvements Andrew Cooper
2021-06-15 16:19 ` [PATCH 1/5] tools/tests: Drop obsolete mce-test infrastructure Andrew Cooper
2021-06-16 6:46 ` Jan Beulich
2021-06-16 12:51 ` Andrew Cooper
2021-06-15 16:19 ` [PATCH 2/5] tools/tests: Drop run runes Andrew Cooper
2021-06-16 6:44 ` Jan Beulich
2021-06-16 13:08 ` Andrew Cooper
2021-06-16 13:59 ` Jan Beulich
2021-06-15 16:19 ` [PATCH 3/5] tests/resource: Rework Makefile Andrew Cooper
2021-06-15 16:49 ` Andrew Cooper
2021-06-15 16:19 ` [PATCH 4/5] tests/cpu-policy: " Andrew Cooper
2021-06-15 16:19 ` [PATCH 5/5] tests/xenstore: " Andrew Cooper
2021-06-15 17:37 ` Andrew Cooper
2021-06-16 6:38 ` Jan Beulich [this message]
2021-06-16 13:22 ` [PATCH 0/5] tools/tests: More cleanup for automation improvements Andrew Cooper
2021-06-16 14:14 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b0de61c-0276-cf06-4eeb-cda9ca990940@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=iwj@xenproject.org \
--cc=jgross@suse.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.