On 21/1/21 9:15 am, Zack Weinberg wrote:
Now we've all had a while to recover from the long-awaited Autoconf
2.70 release, I'd like to start a conversation about where the
Autotools in general might be going in the future. Clearly any future
development depends on finding people who will do the work, but before
we worry about that I think we might want to figure out what work we
_want_ to do.
...
Agree with all that.
The biggest problem i had that wasted the most time is that none of the
documentation gave a good overview of the sequence of steps the main
perl script did to process the files and produce the output, and
intermediate files involved. Using a language like C++ where a
step-by-step debugger like gdb can be used would have been good.
Having a nuts and bolts low level detail of how it all works makes one
much more productive. I'm talking of real software engineering ppl that
understand compilers and not programmers that are really artist dabbling
users. It is the real engineers that are more motivated to understand
and be contributors.
As a result, i only gradually got proficient over a few years, and
having to comprehend a large manual on ancient shell variants and study
M4 didn't help.
M4 is easy if there's a decent tutorial readily available. Currently one
needs to download other manuals and tutorials to get a good idea of it,
and it's a big step for starting programmers.
I understand mostly how things work, but got bogged down in
understanding the perl script. If i mastered it all, i'd think more
about what can be changed or improved.
I did one early iteration of a tool that did the functions of 'make'
using an input description of the files one wanted in a project. It also
had its own shell implementation. Users would need a copy of that shell
installed. An idea was to have the users script automatically build and
install the shell in a location the user or system dictated. Another
option was an automatic download from a trusted place.
I could get more done if i had another go at it, but i'm too busy on a
different tool.
If GNU paperwork gets in the way, just bypass it and release new stuff
as BSD. Then it's truly free.
