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

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2020-12-14 9:33 p.m., Joel Brobecker wrote:
>>> 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.

Indeed, it's a bit annoying that the burden of syncing is only on one
side.

What are the original reasons for staying in sync with gcc?

Instead of manually syncing files, I know Pedro already mentioned the
idea of having a single repo with binutils + gcc + gdb, a bit like
LLVM have moved to a big mono repo.  Especially with gcc being a C++
program as well, we want to share more.  So desyncing from gcc would
make such a move more difficult.  But it's just an idea at this point,
so maybe it's not that important.

Otherwise, just for convenience reasons, it would be nice to think more
of gcc + binutils + gdb (an maybe others) as a single toolchain, and
having consistency and no suprises in how you build them is a good thing
for those build and integrate them.
 
> 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.

I know next to nothing about the top-level configure, because I never
needed to dig into it.

> 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?

I'm not sure I understand.  Do you mean, how do users get to learn about
the configure switches of all projects?

All I know is that you can do "./configure --help=recursive" from the
top-level, but that's not particularly convenient, it just dumps all
the helps from all the configure scripts.  It's good if you want to
find / grep.

Simon