Re: [PATCH v2] Enable GDB build with in-tree GMP and MPFR

Simon Marchi via Gdb-patches
2020-12-27T22:01:31Z

On 2020-12-25 7:05 a.m., Bernd Edlinger wrote:
> Hi everybody,
>
> I have now two possible ways to go forward with the configure options
> for gmp and mpfr.
>
> See the attached patches:
>
> Variant 1: implements traditional configure options
> --with-gmp-include=DIR, --with-gmp-lib=DIR, --with-gmp=DIR,
> --with-mpfr-include=DIR, --with-mpfr-lib=DIR, --with-mpfr=DIR
> but does additionally understand --with-libmpfr-prefix=DIR
> and --with-mpfr=auto/yes/no.
>
> Variant 2: (I already posted that one) keeps all configure options
> as they are now, and just uses the presence of a ../gmp and ../mpfr
> directory to override the gmp and mpfr configure flags.
>
> I would be interested in what you think, and which variant you would
> prefer.
>
>
> Thanks
> Bernd.
>

I really don't have a strong opinion about this, but my only strong-ish
opinion is that I want to minimize the complexity of what we add.
I'm already on the fence about the download script and detecting gmp
/ mpfr in-tree, because I think this is complexity we don't need.
It's not difficult for the user to download and build these two
libraries. It's totally fine for a project to have required
dependencies that the user needs to build first...

We already provide --with-libmpfr-prefix and --with-libgmp-prefix.
Any complexity we add (like adding --with-gmp-include and
--with-gmp-lib on top of that) means more combinations to test for
whoever needs to modify that code next, more chances of breaking
something. IMO it is not a net benefit for the project to add
these additional new switches.

Joel convinced me that it's not so important to stay in sync with
gcc for this. So I'd choose the existing solution of using
AC_LIB_HAVE_LINKFLAGS, since that takes care of all the low level
details for us.

Simon