Re: [RFA/gdb-9-branch] Abort configure immediately if building GDB in tree

[Simon Marchi <simark@simark.ca>]

On 2020-01-05 2:30 a.m., Joel Brobecker wrote:
> Hello,
> 
> Following the discussions on the gdb@ mailing-list regarding
> the fact that GDB 9 is not buildable when configured in tree,
> I propose the following patch for the gdb-9-branch. Ideally,
> I would have liked to propose it for both master and gdb-9-branch,
> but I think toplevel configure is supposed to be coordinated
> between GCC and ourselves. Looking at this patch, I don't think
> it's necessary, since we hope to lift that limitation at some
> point.
> 
> ---------------------------------------------------------------------------
> 
> The move of gnulib to the toplevel directory is causing the GDB build
> to break if configured in tree. We hope to lift that limitation at
> some point but, in the meantime, this commit allows us to abort
> the initial configure right away with a clear error message should
> the user attempt to build in tree.
> 
> ChangeLog:
> 
>         * configure.ac: Abort the build with an error if trying to build
>         GDB in tree.
>         * configure: Regenerate.
> 
> Tested by running the configure script with no argument, --enable-gdb,
> and --disable-gdb; from both the toplevel source directory as well
> as from other directories.
> 
> OK to push to gdb-9-branch?
> 
> Thanks,
> -- 
> Joel
> 
> ---
>  configure    | 9 +++++++++
>  configure.ac | 9 +++++++++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/configure b/configure
> index 6a9719f6091..6273a6a4055 100755
> --- a/configure
> +++ b/configure
> @@ -2279,6 +2279,15 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
>  
>  
>  
> +if test x"${enable_gdb}" != x"no"; then
> +  # For this branch, we do not support building GDB in-tree.
> +  # Try to detect whether we are in this situation or not by
> +  # searching for a couple of known files in the source directory.
> +  if test -f gnulib/update-gnulib.sh -a -f gdb/ChangeLog; then
> +    as_fn_error $? "GDB must be configured and built in a directory separate from its sources" "$LINENO" 5
> +  fi
> +fi
> +
>  progname=$0
>  # if PWD already has a value, it is probably wrong.
>  if test -n "$PWD" ; then PWD=`${PWDCMD-pwd}`; fi
> diff --git a/configure.ac b/configure.ac
> index 7433badc217..25b3392da9a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -33,6 +33,15 @@ m4_include([config/isl.m4])
>  AC_INIT(move-if-change)
>  AC_DISABLE_OPTION_CHECKING
>  
> +if test x"${enable_gdb}" != x"no"; then
> +  # For this branch, we do not support building GDB in-tree.
> +  # Try to detect whether we are in this situation or not by
> +  # searching for a couple of known files in the source directory.
> +  if test -f gnulib/update-gnulib.sh -a -f gdb/ChangeLog; then
> +    AC_MSG_ERROR([GDB must be configured and built in a directory separate from its sources])

Finish the message with a period?

Some people who only know the "./configure && make && make install" recipe
might not know how (or that it's even possible) to configure and build in a
separate directory, so they'll be stuck there.  I think it would be helpful
to give an example of how to do that, like:

    GDB must be configured and built in a directory separate from its sources.

    To do so, create a dedicated directory for your GDB build and invoke the configure
    script from that directory:

      $ mkdir my-gdb-build
      $ cd my-gdb-build
      $ ../path/to/gdb-x.y.z/configure [configure args]
      $ make

Otherwise, that looks good to me.  I'm starting to look at Tom's patchset to move gdbsupport
to the top-level, and I agree that it would be a bit dangerous to finish the work that late
in the cycle, so I'm fine if we prohibit building in the source directory for that release.
It will just look strange that it's the case only for one specific release, but it's not really
a big deal.

Simon