[PATCH 4/5] build: set the scanner --object-type option

[Emil Velikov]

On 18 August 2017 at 13:14, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 28 Jul 2017 13:23:46 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> On 27 July 2017 at 14:36, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> > On Wed, 26 Jul 2017 14:56:20 +0100
>> > Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> >
>> >> From: Emil Velikov <emil.velikov at collabora.com>
>> >>
>> >> Unlike most other scanner users, the core wayland interfaces are
>> >> public ally available via the libwayland DSO.
>> >>
>> >> Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
>> >> ---
>> >>  Makefile.am | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/Makefile.am b/Makefile.am
>> >> index d0c8bd3..4055d04 100644
>> >> --- a/Makefile.am
>> >> +++ b/Makefile.am
>> >> @@ -97,7 +97,7 @@ nodist_libwayland_client_la_SOURCES =               \
>> >>  pkgconfig_DATA += src/wayland-client.pc src/wayland-server.pc
>> >>
>> >>  protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
>> >> -     $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code < $< > $@
>> >> +     $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) --object-type=shared code < $< > $@
>> >>
>> >>  protocol/%-server-protocol.h : $(top_srcdir)/protocol/%.xml
>> >>       $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header < $< > $@
>> >
>> > Hi,
>> >
>> > looks good, but I wonder if the header commands need the type set as
>> > well to avoid the warning.
>> >
>> My goal was to have the option only for "code", but it seems like the
>> scanner will throw a warning when client/server-header instances are
>> missing it.
>>
>> I could omit the warning or simply add have --object-type throughout
>> the Makefile, for consistence.
>
> Hi Emil,
>
> right. The only argument one way or another that I can think of for now
> is that it might be slightly more future-proof if all scanner
> invocations used the same set of options. That way if we need something
> in headers based on object-type, users would already be set. But I
> can't think of what it might be so it's a very weak argument.
>
Hey Pekka,

Fully agree: consistency and keeping it futureproof (future capable
really) sounds like a good idea.
I'll do so with v2 of the series.

-Emil