Re: Do we still need pre-meson compatibility hacks?

[Daniel P . Berrangé]

On Thu, Jan 25, 2024 at 08:54:09AM +0100, Paolo Bonzini wrote:
> Right now configure contains a couple hacks to preserve some of the
> semantics of the pre-meson build system:
> 
> 1) emulation of ./configure by creating a build directory and a forwarding
> GNUmakefile (requested by Kevin)
> 
> 2) creation of symlinks such as x86_64-softmmu/qemu-system-x86_64 and
> arm-linux-user/qemu-arm (requested by Peter)
> 
> Neither of these are a lot of code, but if people aren't relying on them we
> might as well delete them. Do they have any users still?

The latter feels redundant, but the former feels worthwhile as long as we
keep a wrapper cnofigure script around.

It seems like we're not far off being able to do a build with the normal
sequence of

  meson setup build
  meson compile -C build

The creation of the config-host.mak and config-host.h files looks like
the big one. I feel like config-host.mak ought not to even exist. Meson
only consumes a subset of values written into that AFAICT:

$ git grep 'config_host\b'
meson.build:config_host = keyval.load(meson.current_build_dir() / 
'config-host.mak')
meson.build:target_dirs = config_host['TARGET_DIRS'].split()
meson.build:default_targets = 'CONFIG_DEFAULT_TARGETS' in config_host
meson.build:if config_host.has_key('GDB')
meson.build:  summary_info += {'gdb':             config_host['GDB']}
meson.build:summary_info += {'genisoimage':       config_host['GENISOIMAGE']}

and I would have thought meson could detect 'gdb' / 'genisoimage' itself,
and have a meson cli option for target_dirs / default_targets.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|