MESSAGE
| DATE | 2021-01-21 |
| FROM | John Calcote
|
| SUBJECT | Re: [Hangout - NYLXS] Future plans for Autotools
|
Zack,
On Thu, Jan 21, 2021 at 9:12 AM Zack Weinberg wrote:
> On Wed, Jan 20, 2021 at 5:15 PM 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.
>
> > 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
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
