qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] seccomp: Fix build


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] seccomp: Fix build
Date: Mon, 18 Sep 2017 09:31:30 +0100

On 18 September 2017 at 08:46, Jan Kiszka <address@hidden> wrote:
> From: Jan Kiszka <address@hidden>
>
> vl.c includes seccomp.h, thus requires the related CFLAGS as well.
>
> Signed-off-by: Jan Kiszka <address@hidden>
> ---
>  Makefile.objs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile.objs b/Makefile.objs
> index d9cf7ad791..4f1488d65d 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -61,7 +61,7 @@ bt-host.o-cflags := $(BLUEZ_CFLAGS)
>
>  common-obj-y += dma-helpers.o
>  common-obj-y += vl.o
> -vl.o-cflags := $(GPROF_CFLAGS) $(SDL_CFLAGS)
> +vl.o-cflags := $(GPROF_CFLAGS) $(SDL_CFLAGS) $(SECCOMP_CFLAGS)
>  common-obj-y += tpm.o
>
>  common-obj-$(CONFIG_SLIRP) += slirp/

...I get the feeling we're going to get a whole bunch of these
compile errors and fixups as we switch over to trying to specify
package-dependent cflags only on certain source files. Is
there anything we can do to make this changeover more reliable?

In particular I think that just adding a new #include line
to a source file shouldn't suddenly require us to change
the makefile to add a FOO_CFLAGS if we can avoid it. If
it is necessary, then we need to make sure that's a compile
error on all platforms and configurations (including those
where pkg-config happens to set FOO_CFLAGS to the empty string.)

thanks
-- PMM



reply via email to

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