[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future plans for Autotools

From: Russell Shaw
Subject: Re: Future plans for Autotools
Date: Thu, 21 Jan 2021 14:58:20 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]