gdb and ancient GNU autotools

[Eli Schwartz]

On 2/25/24 7:29 PM, Tomasz Kłoczko wrote:
> On Sun, 25 Feb 2024 at 23:32, Mark Wielaard <mark@klomp.org> wrote:
> 
>>
>> Offlist you said that you didn't really got throttled because of those
>> 8 packages you have that are hosted on sourceware none of them need
>> many patches in the first place. So it isn't clear to me if we are
>> actually discussing a real issue or if you are just worried that you
>> could have an issue in theory.
>>
> 
> So .. more than a decade of not updating gdb build automation to be able
> use it with latest GNU autotools tooling is NOT THE REAL ISSUE?🤔
> Really?
> And .. sincerely thank you for your "argumentum ad hominem".


Instead of accusing people of not updating the gdb build automation in
"more than a decade", I would like to invite you to reread the previous
messages in this thread. In particular, it appears you accidentally
skipped over my previous message, in which I said:

----------------------


The main topic is a rant about how GDB but actually the several projects
sharing the same build system, do NOT have the resources right at this
second to update the Autoconf in use, from:
- autoconf 2.69 (the latest version as of December 2020)

to:
- autoconf 2.72 (the latest version as of February 2024)


----------------------


Notice that the currently in use gdb build automation is from 3 and a
bit years ago, not a decade.


> I found that gdb autoconf has some issue with ncurses detection when
> ncurses source code is configured before compiling in some exact way.
> I'm able to fix that but *I'm not able to test the result of that fix*
> (before possible sending PR) because *I'm not able to regenerate all gdb
> build automation .. because for more than decade that gdb automation update
> has been postponed by any cost*.


It hasn't been a decade...

But you can also report a bug and show the patches, then ask if someone
else can help you test it.

I've never seen a project with a complex build system bootstrap that
wasn't both:

- understanding of the challenge it imposes on contributors

- extremely willing to help contributors test their patches when the
  bootstrap defeated them


-- 
Eli Schwartz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x84818A6819AF4A9B.asc
Type: application/pgp-keys
Size: 18117 bytes
Desc: OpenPGP public key
URL: <https://sourceware.org/pipermail/gdb/attachments/20240225/30480d89/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/gdb/attachments/20240225/30480d89/attachment-0001.sig>