Re: [XEN PATCH v7 00/51] xen: Build system improvements, now with out-of-tree build!

[Alex Bennée <alex.bennee@xxxxxxxxxx>]

Anthony PERARD <anthony.perard@xxxxxxxxxx> writes:

> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git 
> br.build-system-xen-v7
>
> v7:
>     Out-of-tree build!
>
>     This mean many more patches. Everything after patch 27 is new.
>
>     There's a few new patch before that, but otherwise are rework of
>     v6.

This is something I've been looking forward to but obviously my QEMU
focused mind meant I did it wrong. Generally I create a builds subdir in
my tree with subdirs for each build flavour. So with:

  /home/alex/lsrc/xen/xen.git/builds/native

And executing:

  ➜  ../../configure
  checking build system type... x86_64-pc-linux-gnu
  checking host system type... x86_64-pc-linux-gnu
  Will build the following subsystems:
    xen
    tools
    stubdom
    docs
  configure: creating ./config.status
  config.status: creating config/Toplevel.mk
  config.status: creating config/Paths.mk

but this leaves a sparse tree:

  🕙15:51:22 alex@zen:xen.git/builds/native  on  review/build-system-v7 (AM) 
[$?] 
  ➜  find .
  .
  ./config.log
  ./config.status
  ./config
  ./config/Paths.mk
  ./config/Toplevel.mk

and no top level Makefile to do the build.

In the QEMU world we symlink the Makefile into the build directory and
then add a little bit of logic to the Makefile to detect incongruent
configurations, for example:

  # 0. ensure the build tree is okay

  # Check that we're not trying to do an out-of-tree build from
  # a tree that's been used for an in-tree build.
  ifneq ($(realpath $(SRC_PATH)),$(realpath .))
  ifneq ($(wildcard $(SRC_PATH)/config-host.mak),)
  $(error This is an out of tree build but your source tree ($(SRC_PATH)) \
  seems to have been used for an in-tree build. You can fix this by running \
  "$(MAKE) distclean && rm -rf *-linux-user *-softmmu" in your source tree)
  endif
  endif

Of course you need some additional definitions to ensure the Makefile is
clear on where it gets the files from.

In "build: adding out-of-tree support to the xen build" you describe the
Linux kernel style which works well where the config can be done after
the fact but I wonder if the configure approach is better suited to
something that needs a bunch of checks running. Is the configure script
pure autoconf? This should work out of the box IIRC.

-- 
Alex Bennée