3 ms·

Is anyone doing and publicizing the git clone vs. tarball work in other projects? I suppose if something has been found, it might be too soon to disclose public

Is anyone doing and publicizing the git clone vs. tarball work in other projects? I suppose if something has been found, it might be too soon to disclose publicly.

cperciva 3y ago
Note that this sort of comparison isn't necessarily trivial. I have code where running `foo --version` out of the git repository will print "foo @@VERSION@@" because that gets substituted with the actual version number as part of the release process, for example.
- elicksaur 3y ago
  A first step could be performance benchmarking a tarball release vs something built from a git clone, maybe? Just a guess since that would be similar to how this was found.
opello 3y ago
The major downside of using git clone build workflows from an autotools project is that your build environment and the developer's may have different enough versions of autotools that macro incompatibility introduces more problems for you to solve. I've noticed this less recently (say 5 years) but still has come up occasionally. While a distributed tarball will have the "developer blessed" autoreconf run and declared good by way of releasing the tarball. Without that process the options are committing generated files (boo) and burdening those that would build from a git clone instead of a distribution tarball with the demands of details from the development environment. That's intentionally a little vague because of the variety of things that can ultimately affect the autotools output. All of this is kind of the design of the autotools build process and could very well be a reason to take a harder look at it and the tradeoffs incumbent on its use.
- TillE 3y ago
  Ultimately autotools isn't doing anything magical, so it's not unusual for cross-platform package managers like vcpkg to simply ignore all that and write their own clean CMakeLists.txt. In this particular case xz-utils actually did support CMake for building liblzma, so that's what you use if you don't care about the command line tools.
  - opello 3y ago
    I never thought it was magical. It's also worth appreciating that in the case of the xz project, the CMake flow is secondary other than for Windows. While I have no evidence one way or another, I wonder if the period in the CMake test that disabled Linux Landlock was actually intentional. Since it disabled it for the CMake build and not the autotools build, it seems like it could have been accidental, unless some significant liblzma consumer builds with CMake and would have otherwise had Landlock enabled.

Is anyone doing and publicizing the git clone vs. tarball work in other projects? I suppose if something has been found, it might be too soon to disclose publicly.

cperciva 3y ago

Note that this sort of comparison isn't necessarily trivial. I have code where running `foo --version` out of the git repository will print "foo @@VERSION@@" because that gets substituted with the actual version number as part of the release process, for example.

elicksaur 3y ago
A first step could be performance benchmarking a tarball release vs something built from a git clone, maybe? Just a guess since that would be similar to how this was found.

opello 3y ago

The major downside of using git clone build workflows from an autotools project is that your build environment and the developer's may have different enough versions of autotools that macro incompatibility introduces more problems for you to solve. I've noticed this less recently (say 5 years) but still has come up occasionally. While a distributed tarball will have the "developer blessed" autoreconf run and declared good by way of releasing the tarball. Without that process the options are committing generated files (boo) and burdening those that would build from a git clone instead of a distribution tarball with the demands of details from the development environment. That's intentionally a little vague because of the variety of things that can ultimately affect the autotools output. All of this is kind of the design of the autotools build process and could very well be a reason to take a harder look at it and the tradeoffs incumbent on its use.

TillE 3y ago
Ultimately autotools isn't doing anything magical, so it's not unusual for cross-platform package managers like vcpkg to simply ignore all that and write their own clean CMakeLists.txt. In this particular case xz-utils actually did support CMake for building liblzma, so that's what you use if you don't care about the command line tools.
- opello 3y ago
  I never thought it was magical. It's also worth appreciating that in the case of the xz project, the CMake flow is secondary other than for Windows. While I have no evidence one way or another, I wonder if the period in the CMake test that disabled Linux Landlock was actually intentional. Since it disabled it for the CMake build and not the autotools build, it seems like it could have been accidental, unless some significant liblzma consumer builds with CMake and would have otherwise had Landlock enabled.