7 ms·

One thing that I am wondering: Why do git repos with totools build chain often include the generated files, like ./configure ? Wouldn't it just be better to pr

by jnxx 6y ago

One thing that I am wondering: Why do git repos with totools build chain often include the generated files, like ./configure ? Wouldn't it just be better to provide the source files (autoconf.ac and Makefile.am) and instruct developers to run "autoreconf" to generate the rest? That would it also make much clearer which files need to be changed if e.g. source files are added.

helaoban 6y ago
You'll find that many projects include a "bootstrap" script that does just that.
geofft 6y ago
It depends on the extent to which the git repo is s product for end users vs. for developers. Traditionally, the product for end users was the source tarball... but also, traditionally, we didn't have git. :) The whole point of autotools is that the output (./configure) is highly portable and can be run on basically any mostly-POSIX-compliant /bin/sh. You don't need to install anything beyond sh and make just to perform the build - compare with a design like Bazel where you need a piece of software to do the build. If the generated files change rarely, checking in and committing the generated files means people who are just making code changes (or no changes at all) don't need to install autotools. Also, there are functionality changes in certain versions of autotools; you might want to make sure your users get a feature that was implemented in a recent version of autotools, but support users who are running on an older OS that doesn't have that version packaged. (If you expect the git repo to be primarily used by developers / contributors instead of end users who are just building it, then you should definitely gitgnore the generated files, but also make sure to include them in the release tarballs. "make dist" will do it. You should also guide end users to download that release tarball instead of an auto-generated tarball of your git sources - GitHub and GitLab both have support for file attachments in their release feature, these days.) In our modern world, this might be less important because installing software (even specific versions of software) is a lot easier. But then our modern world probably deserves something other than autotools, because a lot of what makes autotools hard to work with is the fact that it's intended to translate down to sh/make. (Options I'm aware of that look fairly reasonable include Meson/Ninja, CMake, and I guess Bazel.)
froh 6y ago
Linux distributions like suse or redhat actually bootstrap autotools during build, to.enforce consistency. at least they did 10y ago. you will sometimes run into subtle forward porting issues doing this. that's why not doing this and using the generated Makefile and ./configure is a good idea (tm) for most consumers of packages. in other words: if you're in for adventure and learning, go for autoreconf. https://wiki.debian.org/Autoreconf https://wiki.debian.org/Autoreconf
stabbles 6y ago
In my experience they don't often have a configure file in the repo, but only in the release tarball (some repos on github have an action to setup a tarball with configure script). That way the user only needs a shell and make, nothing else.
- junon 6y ago
  I've seen quite a bit of both. GP isn't wrong.
ksherlock 6y ago
It's extra work to install and run autoconf. With no benefit or necesity unless you're changing the autoconf script. Artificial dependencies are friction that keeps contributors away.
- jnxx 6y ago
  I see that point! On the other hand, it is generally strongly encouraged to keep generated files out of source control repos. Especially since one cannot merge them in a meaningful way.

by jnxx 6y ago

helaoban 6y ago

You'll find that many projects include a "bootstrap" script that does just that.

geofft 6y ago

It depends on the extent to which the git repo is s product for end users vs. for developers. Traditionally, the product for end users was the source tarball... but also, traditionally, we didn't have git. :) The whole point of autotools is that the output (./configure) is highly portable and can be run on basically any mostly-POSIX-compliant /bin/sh. You don't need to install anything beyond sh and make just to perform the build - compare with a design like Bazel where you need a piece of software to do the build. If the generated files change rarely, checking in and committing the generated files means people who are just making code changes (or no changes at all) don't need to install autotools. Also, there are functionality changes in certain versions of autotools; you might want to make sure your users get a feature that was implemented in a recent version of autotools, but support users who are running on an older OS that doesn't have that version packaged. (If you expect the git repo to be primarily used by developers / contributors instead of end users who are just building it, then you should definitely gitgnore the generated files, but also make sure to include them in the release tarballs. "make dist" will do it. You should also guide end users to download that release tarball instead of an auto-generated tarball of your git sources - GitHub and GitLab both have support for file attachments in their release feature, these days.) In our modern world, this might be less important because installing software (even specific versions of software) is a lot easier. But then our modern world probably deserves something other than autotools, because a lot of what makes autotools hard to work with is the fact that it's intended to translate down to sh/make. (Options I'm aware of that look fairly reasonable include Meson/Ninja, CMake, and I guess Bazel.)

froh 6y ago

Linux distributions like suse or redhat actually bootstrap autotools during build, to.enforce consistency. at least they did 10y ago. you will sometimes run into subtle forward porting issues doing this. that's why not doing this and using the generated Makefile and ./configure is a good idea (tm) for most consumers of packages. in other words: if you're in for adventure and learning, go for autoreconf. https://wiki.debian.org/Autoreconf https://wiki.debian.org/Autoreconf

stabbles 6y ago

In my experience they don't often have a configure file in the repo, but only in the release tarball (some repos on github have an action to setup a tarball with configure script). That way the user only needs a shell and make, nothing else.

junon 6y ago
I've seen quite a bit of both. GP isn't wrong.

ksherlock 6y ago

It's extra work to install and run autoconf. With no benefit or necesity unless you're changing the autoconf script. Artificial dependencies are friction that keeps contributors away.

jnxx 6y ago
I see that point! On the other hand, it is generally strongly encouraged to keep generated files out of source control repos. Especially since one cannot merge them in a meaningful way.