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

[Joel Brobecker <brobecker@adacore.com>]

> >>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> >
> > Simon> So with this patch, we now have:
> >
> > Simon>   --with-gmp-include=DIR  GMP include directory
> > Simon>   --with-gmp-lib=DIR      GMP lib directory
> > Simon>   --with-gmp=DIR          GMP install directory
> > Simon>   --with-libgmp-prefix[=DIR]  search for libgmp in DIR/include and DIR/lib
> > Simon>   --without-libgmp-prefix     don't search for libgmp in includedir and libdir
> >
> > Simon> I think that's getting a bit confusing.  That's too many ways to set gmp
> > Simon> paths, with -with-libgmp-prefix and --with-gmp doing the same thing.
> >
> > FWIW we have the same situation with MPFR.
> 
> :(

Yeah, my reaction exactly when Bernd made me discover this problem.
There might be other options in the same category; we should
double-check (busy this week, but I can have a look during the weekend
if noone beats me to it).

> > Simon> It might mean that we have to stop using AC_LIB_HAVE_LINKFLAGS
> > Simon> though, or customize it.
> >
> > Yes.  Perhaps alternatively we could promote its use to the top level.
> > It's maybe a pain to do that.
> 
> Perhaps, but --with-{gmp,mpfr} would need to be kept as backwards
> compatibility.  I think it would be hard to convince the gcc people of
> the benefits of such a change.

Here's a radical question: Do we really need to stay in sync with GCC,
at this point? What are the benefits and requirements of doing so?
Because GCC doesn't coordinate with us when they make changes to
the toplevel configury, we're only going to get into these problems
more.

In fact, how much does the toplevel configure really need to do?
Intuitively, it doesn't really need to do very much, if we ignore
all the stuff that's GCC-specific.

A more relevant conundrum, for me, might be to look at keeping
binutils and GDB in sync in terms of the options being used.

And then we have the question of how to provide users who want to
configure parts or all of binutils-gdb what options they can use,
and what they do. I don't know how easy we can do that via the
toplevel configure's --help. One interesting question is: Would
doing so help us avoid inconsistencies with binutils?

So, as you can see, the question is much larger than just GMP/MPFR.

> > Simon> An alternative to downloading the pre-requisites would be to check them
> > Simon> in the repo.  We do it for readline already: there is a copy in the
> > Simon> repo, which is used by default, but you can specify
> > Simon> --with-system-readline if you want to use the system's readline.  We
> > Simon> could do the same with gmp and mpfr.  The downside is that we deviate a
> > Simon> bit from how gcc does, the the upside is that it's simpler, IMO.
> >
> > For me the main difference here is that, historically, we've had to
> > patch readline.  In cases where GDB has never needed to patch a
> > dependency (libiconv comes to mind), we've haven't bothered.
> 
> Ok, when you put it like that then it doesn't make as much sense to
> check the code in the repo.
> 
> Thinking about it a bit more, I don't see why gmp and mpfr get this
> treatment, what is it that makes them different from other dependencies?
> If you want to build GDB with XML support, you download and build expat,
> or install it using your package manager.  Why can't you do the same
> with mpfr/gmp?  The only reason for us I can see is "because gcc does
> it" and we share the build system with gcc.  But otherwise, I'd just
> tell people to build/install mpfr and gmp themselves.
> 
> Simon

-- 
Joel