4 ms·
It's common but it's plain wrong. A "release" should allow to build the project without installing dependencies that are only there for compilation. Autotools
by bhaak 3y ago
It's common but it's plain wrong. A "release" should allow to build the project without installing dependencies that are only there for compilation.
Autotools are not guaranteed to be installed on any system. For example they aren't on the OSX runners of GitHub Action.
It's also an issue with UX. autoreconf fails are pretty common. If you don't make it easy for your users to actually use your project, you lose out on some.
- GrayShade 3y ago> A "release" should allow to build the project without installing dependencies that are only there for compilation. Like a compiler or some -devel packages?
- bhaak 3y agoIf the compiler is some customized or hard to build version then yes, they should be included. The more steps you add to get to the final product the more likely it is to run into problems.
- cryptonector 3y ago> [...] A "release" should allow to build the project without installing dependencies that are only there for compilation. Built artifacts shouldn't require build-time dependencies to be installed, yes, but we're talking about source distributions. Including `./configure` is just a way of reducing the configuration-/build-time dependencies for the user. > Autotools are not guaranteed to be installed on any system. [...] Which is why this is common practice. > It's common but it's plain wrong. Strong word. I'm not sure it's "plain wrong". We could just require that users have autoconf installed in order to build from sources, or we could commit `./configure` whenever we make a release, or we could continue this approach. (For some royal we.) But stopping this practice won't prevent backdoors. I think a lot of people in this thread are focusing on this as if it was the source of all evils, but it's really not.