> This may be problematic because it’ll require all users of our chmlib crate (and their users) to have Autotools installed.
Autoconf creates a portable shell script, right? No need to have it installed just to build the project.
Autoconf creates a portable shell script, right? No need to have it installed just to build the project.
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).
No, parent answers the question, "What is the difference between the git tree and a dist tarball?" Which is self-evidently (and unhelpfully) "you don't need autotools installed with the dist tarball". My questions are: Why does this difference exist? Why would you not track everything necessary to build a library in git? How is the dist tarball built differently than just zipping the current git tree?
"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".
I'm just being pedantic. It's a problem...
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.
CMake based projects almost always cross compile easily.