5 ms·
One minor nit about the projects use of autoconf / automake. Projects should please check the generated files into git. Sure, they're auto-generated. But 90
by adekok 11y ago
One minor nit about the projects use of autoconf / automake. Projects should please check the generated files into git. Sure, they're auto-generated. But 90% of the time when they're not in git, I discover that I have a different version of autoconf, and I can't even build "configure" in order to build the project.
The cost of a few more bytes in git is more than outweighed by the benefits of allowing people to use your software.
- tobbez 11y agoIf you intend to use the software, you should generally download a release. Releases usually (as is the case here) include the configure scripts.
- DiabloD3 11y agoThis is inherently wrong. Auto-generated files should NEVER be in git. However, they should be in the stable release tarball.
- alextgordon 11y agoHow am I supposed to contribute to your project if the files required to build it are in one place (the tarball) but patches have to be made in another (the git repo)? If your best practices require you to make potential users and contributors jump through hoops, then maybe those best practices are a bit shit.
- therein 11y agoI do not understand this debate. The project should decide on which autotools version to use and everyone contributing should make sure everything can be generated and installed with roughly the following: > autoreconf -ivf > ./configure > make > sudo make install
- DiabloD3 11y agoWell, not only that, autoconf and automake files themselves can set a minimum version. For the problem case of "my version was old, but still executed, and produced a build system that wouldn't build", this has already been handled for a long long time. But yeah, either autoreconf or explicit autogen.sh works.
- paulddraper 11y agoChecking in build products is not about saving a couple bytes. It's about having a DRY codebase that isn't of out sync with itself.