On 12/16/20 8:33 AM, Joel Brobecker wrote:
> 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...
> 

That may be because this does not break anything if it is not available.
I for one did not notice anything before I knew that mpfr could be missing...

I looked at AC_LIB_HAVE_LINKFLAGS and I am surprised that it considers
to look for *.la/*.a/*.so at $prefix/lib directory instead of for instance
simply using pkg-config.

Using prefix/lib and prefix/include is also a bit unexpected, because that
is where I would normally expect the generated libraries from gdb to be
installed, instead of used from to build the gdb package.
And, it is also not clear if the user uses make install DESTDIR=X to install
everyting in X/prefix/..., for instance when prefix=/

So I think the configure flags for GMP can still be changed if we want, but the
AC_LIB_HAVE_LINKFLAGS-style configure flags for MPFR have already been there
for too long to simply remove them now.  But I still think that it would
be nice to be more compatible with other configures, maybe at least
understand the --with-gmp-include --with-gmp-lib where there is no equivalent
for at the moment.

However I think I found a way to fix the in-tree build issue without adding
now configure options at all.

How would you like this new patch?


Thanks
Bernd.