The tree only contains configure.in, not the generated configure output, and Makefile.am, not the generated Makefile.in. You do need the entire autotools suite installed for it to build.

Why they published it like this is beyond me, however. The whole point of autotools is not making your users install them (unlike CMake and virtually every other build system for C there is).

That's not true. If you build from a dist tarball, you do not need auto tools installed. You usually do if you build from a git repo, however.

I think we misunderstood each other?

"It" in my post referred to the Rust cargo package in question. The package ships configure.in, but not the generated configure. You do need autoconf for configure.in -> configure. Similarly, it ships Makefile.am, but not the generated Makefile.in for use with configure.

Note how I said "The whole point of autotools is not making your users install them".

How/why is a dist tarball not exactly the same as a zipped up git tree?

Same as a npm package is usually js code and doesn't require you to run the typescript compiler, a dist tarball shouldn't require you to run autotools but just contain their output.

The parent you're replying to answers that question. And if your question is meant rhetorically, it doesn't contribute to the discussion either.

"make dist" does stuff other than just make a tarball -- like insert a version number into a header &etc.

"portable" to different Unices, right? I'm on Windows, for example.

Sure but that's a different problem than "it’ll require all users of our chmlib crate (and their users) to have Autotools installed."

I'm just being pedantic. It's a problem...

Autotools is rarely portable. I've been doing a lot of cross compiling recently: the vast majority of autotools projects can't be cross compiled. Sure autotools itself supports it, but something required to make it work didn't get connected up and so you can't do it.

If you want to natively compile on a fairly recent linux with the common standard libraries autotools works well. Even though autotools was written to work around these differences, in most cases the developer didn't hook into autotools detecting that difference and so it doesn't work.

Cross compiling to what? Autotools is probably the most portable piece of software out there as far as Unices are concerned.

Embedded Linux on arm. Nothing very far out really. Note that I'm careful not to blame autotools, it is the user's fault, there are a couple projects that use autotools and cross compile easily. The vast majority do not.

CMake based projects almost always cross compile easily.