[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