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

Joel Brobecker
2020-12-16T07:33:44Z

Hi Simon,

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

I don't know. It was like that when I first joined the project
20 years ago. I assumed it was convenient in the CVS days to
have everything under the same "roof", especially for those
who want to rebuild the works, knowing that CVS allowed partial
checkouts for those who diddn't.

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

It'd be interesting in knowing more about what it is that we would
be sharing. GCC is absolutely huge (4.5GB), and GDB isn't bad either
(1.2GB). Both GCC and GDB move very fast, so reuniting them would be
causing a large burden both ways for everyone. If we do, I feel
it has to be for strong reasons.

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

It would be nice, but is that a sufficiently strong reason to break
with the past?

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

I didn't know that! This answers my question.

To recap where I am on this discussion: First, I need to be honest
and upfront in saying that I can't seem to be able to summon the energy
to motivate myself towards discussing reunification or even just making
GCC and binutils-gdb more consistent in the naming of the configure
options.

In fact, pending more info, I would still prefer we break the minimal
tie we have left in terms of synchronization with GCC, and use that
to help ourselves simplify and clarify, without breaking the existing
option.

In the meantime, if the group decides after discussion that the name
of the configure options in GDB for GMP are wrong, and must be changed
to follow GCC's lead, then so be it, I will change it. It'll be a bit
of a heartbreaker for me because:
- It breaks consistency with the way we have been handling dependencies
in GDB;
- We won't be able to use this nice macro to implement those options,
and will end up hand-writing them the same way toplevel configure
does (it seems like a lot of code, although I would hope I can
do this better and shorter).
Note that no one has complained about MPFR in the years we've had it...

--
Joel