qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [PATCH v2] configure: warn if not using a separate build directory
Date: Tue, 31 Mar 2020 17:12:35 +0100

On Tue, 31 Mar 2020 at 17:05, Eric Blake <address@hidden> wrote:
>
> On 3/31/20 10:51 AM, Daniel P. Berrangé wrote:
> > +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:"
>
> Per Kevin's response, we may want to tweak this wording slightly; maybe:
>
> Support for running the 'configure' script directly from the source
> directory is deprecated.  In-tree builds are not covered by automated
> testing and are liable to break without warning.  Future releases may
> change the default location of built executables for an in-tree build,
> or drop in-tree build support altogether.  Users are strongly
> recommended to switch to a separate build directory:

I now feel that, given that we've had various people say they
want to retain at least the basic in-tree build commands and are
willing to put in a wrapper to make it keep working, that this
deprecation wording is a bit strong. I don't think that it
much serves our users to say "this will go away" and then
implement the compatibility wrapper -- we've caused them
to unnecessarily change what they're doing, and then reduced
the value of the compat-wrapper work we do. A more gently
phrased note that we recommend use of out-of-tree builds
would be sufficient I think.

(That is, the idea of notes in the release notes and configure
is to signpost to our users the direction we think the
project is going in, so they are not unpleasantly surprised
in future. For this to work the signpost should be pointing
reasonably in the direction we plan to head, rather than somewhat
askew from it :-))

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]