--disable-system --enable-$some_system_feature: fail?

[Michael Tokarev]

Hi!

We've an interesting effect out of our --enable-foo stuff.
For example,

  ./configure --disable-system --enable-gtk

this will fail during build time, this way:

 In file included from ui/x_keymap.c:15:
 ui/trace.h:1:10: fatal error: trace/trace-ui.h: No such file or directory

This is because in meson.build, we first have

if have_system
  trace_events_subdirs += [
    'ui',
  ]
endif

and later we have

subdir('ui')

which, in ui/meson.build, in turn has

if gtk.found()
  gtk_ss.add(gtk, vte, pixman, files('gtk.c'))
  ui_modules += {'gtk' : gtk_ss}
endif

So we end up building ui/gtk.c (which includes trace-ui.h)
but not building trace-ui.h.

It is interesting that ui/meson.build does not check for
have_system at all, ditto for inclusion of subdir('ui'),
but rely solely on gtk.found().

Arguable it is a bug in ./configure options, since one
can't enable gtk without enabling system as well.

This is a widespread thing: many other similar options
behave in a similar way.

Can we fix this somehow to be at least consistent?

Maybe we can guard some subdir('foo') with if have_system
or have_user?  Note there are things like, say, sdlaudio,
which is not in ui/ but will fail in the same way unless
also guarded in audio/meson.build (or whole audio/ should
be omitted without have_system just like ui/).

BTW, can't we always generate trace stuff? I mean, why that
one is guarded with have_{system,user}, while actual subdir
inclusion is not? Maybe we can fix just this inconsistency?

Thanks,

/mjt