4 ms·

> autotools are great, but at the same time it's a monstrosity, and easy to misuse (you should never commit the configure script, because it's the autotools tha

> autotools are great, but at the same time it's a monstrosity, and easy to misuse (you should never commit the configure script, because it's the autotools that are supposed to generate it according to the platform it's running on). The configure script is not generated according to the platform it is running on. The whole reason tbe configure script is such a monstrosity is because its supposed to be portable, its written in the lowest common denominator of shell. You are supposed to distribute it. Its also fine to check in if you want end users building directly from VC rather than from tarballs. Just dont modify it by hand.

linkdd 6y ago
From my experience, `autoreconf -i` is responsible for generating the configure script from a configure.ac file, so I assumed some platform-specific logic was happening. I always wrapped it up in a autogen.sh script that I did commit. Also, end users generally prefer prebuilt binaries, if one wants to compile the software themselves, I expect him to have autotools installed, and mention it as a requirement in the README.
- knorker 6y ago
  I would say that best practice is to NOT commit the generated files, but DO include them in release tarballs. Because release tarballs are exactly what need to be portable to all your users.
- admax88q 6y ago
  Autotools and the configure script come from a history of distributing software purely as source code instead of binaries. From the early GNU days. https://www.gnu.org/prep/standards/standards.html#Managing-Releases https://www.gnu.org/prep/standards/standards.html#Managing-R... The intention was that software would be released as source code "tarballs" and contain a configure script, written in the lowest common denominator scripting language to configure that source code to compile on the users system. Additionally by distributing the configure script itself instead of configure.ac, users tend to need fewer dependencies that they don't already have. It's _less_ applicable now that most users get pre-built binaries from package managers and it just feel pretty antiquated overall. But yeah the intention is that configure is platform agnostic and prepares your source code tree to build on the current platform. Whereas autoconf/autoreconf is intended as a tool for the developer to make writing "configure" a lot easier.

linkdd 6y ago

From my experience, `autoreconf -i` is responsible for generating the configure script from a configure.ac file, so I assumed some platform-specific logic was happening. I always wrapped it up in a autogen.sh script that I did commit. Also, end users generally prefer prebuilt binaries, if one wants to compile the software themselves, I expect him to have autotools installed, and mention it as a requirement in the README.

knorker 6y ago
I would say that best practice is to NOT commit the generated files, but DO include them in release tarballs. Because release tarballs are exactly what need to be portable to all your users.
admax88q 6y ago
Autotools and the configure script come from a history of distributing software purely as source code instead of binaries. From the early GNU days. https://www.gnu.org/prep/standards/standards.html#Managing-Releases https://www.gnu.org/prep/standards/standards.html#Managing-R... The intention was that software would be released as source code "tarballs" and contain a configure script, written in the lowest common denominator scripting language to configure that source code to compile on the users system. Additionally by distributing the configure script itself instead of configure.ac, users tend to need fewer dependencies that they don't already have. It's _less_ applicable now that most users get pre-built binaries from package managers and it just feel pretty antiquated overall. But yeah the intention is that configure is platform agnostic and prepares your source code tree to build on the current platform. Whereas autoconf/autoreconf is intended as a tool for the developer to make writing "configure" a lot easier.