Re: [PATCH] configure: warn if not using a separate build directory

[Eric Blake]

On 3/31/20 5:37 AM, Daniel P. Berrangé wrote:
> Running configure directly from the source directory is a build
> configuration that will go away in future. It is also not currently
> covered by any automated testing. Display a deprecation warning if
> the user attempts to use an in-srcdir build setup, so that they are
> aware that they're building QEMU in an undesirable manner.
>
> Signed-off-by: Daniel P. Berrangé <address@hidden>
> ---
>   configure | 30 ++++++++++++++++++++++++++++++
>   1 file changed, 30 insertions(+)

It sounds like you already have a v2 coming up to address Phillipe's 
comments, but I'd be happy to see this concept make it into v5.0.

> diff --git a/configure b/configure
> index e225a1e3ff..1ab7492ab5 100755
> --- a/configure
> +++ b/configure
> @@ -3,6 +3,19 @@
>   # qemu configure script (c) 2003 Fabrice Bellard
>   #
>   
> +BUILDDIR=$(pwd)

Why fork out to 'pwd', when we can rely on $PWD for the same answer? 
Note that both $(pwd) and $PWD $BUILDDIR always give an absolute (but no 
necessarily canonical) path, which means...

> +SRCDIR=$(dirname "$0")
> +
> +ABS_BUILDDIR=$(realpath $BUILDDIR)

...calling this ABS_BUILDDIR is a misnomer (it was already absolute). 
What it is really doing is chasing through symlinks to result in a 
canonical name, particularly since unless you have absolute names, using 
only string comparison to see if two filenames are equivalent will have 
false negatives (/tmp vs. /tmp/., for example).

> +ABS_SRCDIR=$(realpath $SRCDIR)

Not robust if there are spaces in the directory names.  Safer would be
ABS_BUILDDIR=$(realpath -- "$BUILDDIR")
and similarly for ABS_SRCDIR.

> +
> +in_srcdir=no
> +if [ "$ABS_SRCDIR" == "$ABS_BUILDDIR" ]

Bashism. You MUST spell this '=', not '==', since configure is run under 
/bin/sh which might be dash which does not understand ==.

> +then
> +    in_srcdir=yes
> +fi
> +
> +
>   # Unset some variables known to interfere with behavior of common tools,
>   # just as autoconf does.
>   CLICOLOR_FORCE= GREP_OPTIONS=
> @@ -6799,6 +6812,23 @@ if test "$supported_os" = "no"; then
>       echo "us upstream at address@hidden."
>   fi
>   
> +if test "$in_srcdir" = "yes"; then
> +    echo
> +    echo "WARNING: SUPPORT FOR IN SOURCE DIR BUILDS IS DEPRECATED"
> +    echo
> +    echo "Support for running the 'configure' script directly from the"
> +    echo "source directory is deprecated and will go away in a future"
> +    echo "release. In source dir builds are not covered by automated"
> +    echo "testing and are liable to break without warning. Users are"
> +    echo "strongly recommended to switch to a separate build directory:"
> +    echo
> +    echo "  $ mkdir build"
> +    echo "  $ cd build"
> +    echo "  $ ../configure"
> +    echo "  $ make"
> +    echo
> +fi

You know, it WOULD be possible to further enhance this to actually 
create 'build' as well as a shim GNUmakefile that would auto-forward on 
to building directly in build, so that you maintain the illusion of an 
in-place build (other than all the build artifacts now living in a 
different location), and muscle memory for in-tree 'make' still works; 
I've posted elsewhere and will repeat here the contents of my GNUmakefile:

# Hack for redirecting while reminding myself to use distinct builddir
ifeq ($(MAKECMDGOALS),)
recurse: all
endif
%: force
        @echo 'changing directory to build...'
        @sleep 2
        @$(MAKE) -C build -f Makefile $(MAKECMDGOALS)
force: ;
.PHONY: force
GNUmakefile: ;


But we could do that as a patch on top of yours.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org