Zack, On Thu, Jan 21, 2021 at 9:12 AM Zack Weinberg <zackw@xxxxxxxxx> wrote: > On Wed, Jan 20, 2021 at 5:15 PM Zack Weinberg <zackw@xxxxxxxxx> 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. > > > 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. > > Thanks for all the great thoughtful responses that came in overnight! > I see many people expressing similar sentiments, so rather than > respond to each of you individually I'm going to summarize and reply > to each strand in this one message. > > I like the way you think. But, as your response so clearly indicates, there's actually very little we can change in a radical way: 1. We shouldn't change the underlying language(s) and tools because one of the key strengths of the Autotools is (their products') ability to run everywhere without off-box dependencies. In my humble opinion, nothing the GNU project has ever done comes close to the value they created by designing the Autotools to work as seamlessly (for the end-user) as they do. Download a tarball, unpack, ./configure && make. How much simpler could it be? No additional tools to install - everything required is already there - for the end user. Of course, developers may need to install a few additional tools to build these tarballs from the base source repository, but developers are not end-users and those are the "customers" GNU was trying to appease. If you build from source repositories, you're effectively a developer, not an end-user - not always the case, but 98% of the time this is true. Additionally, making such changes would require long man-hours of unpaid effort - something the world is not willing to give. Gone are the days of university grad students who know enough of what they're talking about to effectively take on this task for the sake of their educational goals (this is the way these tools started, after all). In fact, as much as they'd hate to admit it, the GNU project has become much more corporate than educational today. But let's not get bent out of shape by it - the truth of the matter is that no one does anything for free (you yourself solicited funding for the 2.70 update - which did NOT ultimately come from philanthropic individuals. 2. The Autotools are actually more transparent than any other build tools out there. All these other tools' (cmake, maven, etc) - that purport to be so much simpler because they insulate the user from the underlying details of the build process - these tool's primary failure is that this very insulation keeps users from being able to make the changes they need to accomplish their unique project-specific build goals. Anyone who has nothing but good things to say about this aspect of cmake, maven, gradle, or whatever, has simply not worked on a project that requires them to move far enough away from the defaults. I've used them all and I've spent hours in frustration trying to determine how to work around the shortcomings of some "do-all" (except what I want) tool function. This is simply not an issue with the Autotools. As someone mentioned earlier in this thread, you can drop shell script into a configure.ac file, and make script into a Makefile.am file. That is the very definition of transparency. No other tool in existence allows this level of flexibility. The most interesting feedback I read in the responses was that the Autotools had an appalling lack of documentation which - ironically - is actually not true. At the risk of sounding self-serving, I'll say this: in the research I did for my book (Autotools, No Starch Press, 2019), I primarily (95%) used the GNU Autotools documentation as reference sources. The information is all there and actually very concise - too concise sometimes. The problem with it is two fold. First, the documentation for GNU projects is most often written by the author of the code - that's the open source way, after all. This brings with it all sorts of issues that most corporate documentation (inadvertently) bypasses by standard corporate siloing protocol - that is, they relegate doc writing to doc writers, who are often not experts in the code, so they have to spend the time researching the product from a user's perspective. This is exactly the perfect storm of events that (usually) generates pretty good documentation. Second, the documentation is written in a manner that is not conducive to fast learning. There are two types of instructive material. The first is reference material that, by its very nature, requires the user to read and absorb significant amounts of information until they hit a critical mass of understanding - an exponential learning curve that starts out long and slow - at which point they avalanche into the steeper portion of the curve. The other type of doc provides a much more linear learning experience - it starts out with enough background information to keep the reader well entrenched in the learning process, providing examples and discussion of why things work the way they do, so they become par-experts at subsets of the data, until they realize (almost surprised) they understand enough to do the things they want to without too much pain. Most readers are not patient enough to get past the long, slow portion of the exponential curve. People want to pick up a book or a manual and become an expert within the first chapter - they have busy lives and don't want to spend a good portion of it learning esoteric tools by absorbing long reference manuals. Therefore, if the documentation were to be supplemented with a good getting-started guide, it would go a long way toward improving the documentation. Regards, John
