Re: gdb and ancient GNU autotools

On Sat, 24 Feb 2024 at 17:22, Sam James <[email protected]> wrote:

> Again, I actually agree with needing to move to 2.72. But you've misread
> my previous message.
>

Yep. My fault.
Sorry.

Also note that while autoconf-2.69 is old, it took a long time for
> autoconf-2.7{0,1} to be released, so it's not quite a fair comparison.
>

Latest one is 2.72 .. released +3 months ago (which in the context of GNU
projects still is cadence below Palnck time).

Generally the issue is that maintaining anything placed on gnu.org is like
dropping something into a black hole. For observers from outside of
that hole stuff moves but slower and slower.
This is partially in context of gcc/binutils/gdb as well. Just check any OS
distro source packages and in each of these distros you can find tenths if
not sometimes hundreds of patches taken from random places fixing different
JFDI issues.
Additionally main git repos all of those projects on
https://sourceware.org/git/ are served from http server which (time to
time) throttles the number of requests/s which sometimes blocks
completely automatic downloading of the patches from exact commits over
https:// interface during automated builds.

Why those repos are not moved yet to github or even own instance of the
gitlab to provide OOTB proper cross refs between commits, discussions
MRs/PRs, issue tickets and commit comments for me is kind of a mystery ..
(IMO change that would allow move saved paid man/h resources from
maintaining that platform to something more productive like review tickets)

All tooling around constantly improves allowing speeding up of the
development processes of many projects and sticking with old platforms is
nothing more than just discouraging to even try to touch something trivial.
Sorry for maybe a few bitter words but just please look at LLVM stack.
Thay have a lot of problems but at least from that angle it is
squeaky clean.
(just please do not comment above because it is kind of rhetorical part and
focus on gdb subject)

Going back to the subject: someone at least started thinking about starting
doing something to move away from those ancient GNU autotools versions
(probably kicking a few as*ess on integrating properly some
libtool changes) or move to meson/cmake?
IMO move to meson/cmake has that advantage that would allow to stop
worrying about proper build automation features/shape necessary for
gdb/gcc/binutils as those projects have enough robust maintainers.

Someone at least made the strategic decision what should happen in that
area?🤔
And/or who has any partial work done going towards that target?
And/or where are those changes maintained/available?🤔

kloczek
-- 
Tomasz Kłoczko | inkedIn: http://lnkd.in/FXPWxH