qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX


From: Liviu Ionescu
Subject: Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX
Date: Tue, 8 Feb 2022 22:39:18 +0200


> On 8 Feb 2022, at 21:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> I've cc'd some people who might have an opinion on whether this
> something we want to add upstream. (Patch/thread below for context.)

Sure. For a better understanding of the reason why I found this useful: I use 
QEMU extensively in CI tests, in various environments, and, to be sure that the 
tests always run in a reproducible environment, I have binary packages with 
various tools; the tested packages have dependencies on explicit versions of 
the tools, for example:

- 
https://github.com/micro-os-plus/micro-test-plus-xpack/blob/9c23c7d7b8fdba849602bcf8ad4c9e64e7e2837a/package.json#L505

Seeing the branded greeting in a console log is a visual confirmation that the 
test script used the desired version, and not another version picked up by 
mistake when using an incorrect PATH.

I hope that other distributions may find this useful too.

> On the actual implementation, if you make the #define expand
> out to either the empty string "" if the user specified no prefix
> or "user-specified-prefix " with a trailing space if they did,
> then you can avoid a lot of the need for ifdefs in the rest of
> the patch.

Yes, I mentioned in a previous message that I would prefer such a solution; the 
initial implementation did not rely on meson for setting this macro, so it was 
safer to use #if/#endif; later I figured out a way to configure meson to 
process the configure option, and noticed that the code would be simpler if we 
assume the definition is always present.

> Or maybe we could have a QEMU_PROG_NAME(S) macro
> that expands to S if no prefix specified or "prefix S" if there
> is one.

Sure, any better ideas will be appreciated.

> But don't respin the patch until we've decided if we
> like the concept.

Ok.

Thank you,

Liviu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]