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

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

On 12/15/20 3:39 PM, Simon Marchi wrote:
> 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.
> 

One thing, that might be useful here, is making the toplevel
configure script print an error, when GMP is not available,
instead of having the error later when gdb/configure runs.

For instance when the toplevel configure detects gcc needs
to be built, it checks the availability and correct versions if
GMP/MPFR/MPC/ISL while it does nothing when gdb is built.

My patch does not yet touch that logic, but it is probably
a next logical step.

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

Bernd.