3 ms·

I have found standard distros on relatively recent versions don't have issues with configure / make / make install, or at least issues I can solve fairly easil

I have found standard distros on relatively recent versions don't have issues with configure / make / make install, or at least issues I can solve fairly easily with googles

kazinator 4y ago
With the release materials you won't see problems on mainstream distros doing configure && make && make install. I'm talking about cloning the program's git repo and working with that. GNU programs don't include the generated configure script in their repos; you have to boostrap that first, and you need all the AutoCruft, in the correct versions which that git baseline of the program wants. It's completely insane. It should be that to create a release of gnu-whatever-1.2.3 you just create a tarball directly out of git using the 1.2.3 version tag. That is the release. But that's not how it works; a release that doesn't require AutoTools has to be specially prepared. Sometimes I have cheated to build a GNU program from sources. I would find the closest matching release tarball and unpack it over the cloned git repo, then run ./configure and all that. Carefully git-reset any differences and so on.
- monero-xmr 4y ago
  You seem to have a lot of experience with some hairy stuff. Mine consists of creating some open source C projects using autotools, and also cloning / building perhaps 7 projects I frequently use on Ubuntu and popOS which I have not struggled with. But totally believe that autotools hell is widespread. My total nightmare experience has been with CMake, with a project that mixed C and C++. IIRC it had to do with trying to get something to work on LLVM / macOS which it wasn't originally supported for.
  - kazinator 4y ago
    To be clear, I'm dead set against CMake. I would never voluntarily agree with that being introduced anywhere for any purpose. The concept is bad and the implementation is atrocious. In no uncertain terms, CMake is harmful garbage.
    - mathstuf 4y ago
      I'm curious: do you mind being a bit more specific? Feel free to send an email (easily discoverable from Git commits I make and end up on Github; same handle here and there). (FD: CMake developer) I certainly understand a lot of the gripes that people have had, but the amount of tribal knowledge for obscure platform behaviors encoded in CMake is…vast. I am certainly in the "things need to improve" camp, but I don't think burning all the bridges that have been built is the way to go either.
- tomn 4y ago
  While what you said is true, for outsiders it misses the 'why' (which I'm sure you are aware of!). The idea with autotools is that the generated configure script (and other assorted files) is supposed to be forwards and backwards compatible with different systems. It's not perfect, but the behaviour is mostly locked down at the time it is built, based on the particular set of macros it is generated with. There are definitely aspects of this which don't work (it's nearly impossible to test, getting specific versions of autotools is presumably a PITA, and the make-in-bash-in-m4 language is deeply cursed), but the overall design does make some things better. For example, if your project needs a specific version of cmake, your users will have to figure out how to install it, but if your project requires a specific version of autotools, only your developers need to install it. (FWIW autotools is on my 'never again' list of technologies; it's incredibly cursed)
  - verall 4y ago
    As long as your policies are set correctly (not that this is particularly easy), your project will only need a version of CMake or newer, not a specific version.
    - tomn 4y ago
      Yeah, they are quite good at compatibility. In practice there may often be an upper version limit if you happen to use any features which eventually get deprecated or removed.
rleigh 4y ago
The reason for the recent stability is that the Autotools have been essentially unmaintained for the past 15 years. When there were steady releases back in the early 2000s, we experienced regular incompatibilities and breakage. Today, there are occasional releases again, but the tools have painted themselves into a corner--it's almost impossible to make any change of note without breaking things.

I have found standard distros on relatively recent versions don't have issues with configure / make / make install, or at least issues I can solve fairly easily with googles

kazinator 4y ago

With the release materials you won't see problems on mainstream distros doing configure && make && make install. I'm talking about cloning the program's git repo and working with that. GNU programs don't include the generated configure script in their repos; you have to boostrap that first, and you need all the AutoCruft, in the correct versions which that git baseline of the program wants. It's completely insane. It should be that to create a release of gnu-whatever-1.2.3 you just create a tarball directly out of git using the 1.2.3 version tag. That is the release. But that's not how it works; a release that doesn't require AutoTools has to be specially prepared. Sometimes I have cheated to build a GNU program from sources. I would find the closest matching release tarball and unpack it over the cloned git repo, then run ./configure and all that. Carefully git-reset any differences and so on.

monero-xmr 4y ago
You seem to have a lot of experience with some hairy stuff. Mine consists of creating some open source C projects using autotools, and also cloning / building perhaps 7 projects I frequently use on Ubuntu and popOS which I have not struggled with. But totally believe that autotools hell is widespread. My total nightmare experience has been with CMake, with a project that mixed C and C++. IIRC it had to do with trying to get something to work on LLVM / macOS which it wasn't originally supported for.
- kazinator 4y ago
  To be clear, I'm dead set against CMake. I would never voluntarily agree with that being introduced anywhere for any purpose. The concept is bad and the implementation is atrocious. In no uncertain terms, CMake is harmful garbage.
  - mathstuf 4y ago
    I'm curious: do you mind being a bit more specific? Feel free to send an email (easily discoverable from Git commits I make and end up on Github; same handle here and there). (FD: CMake developer) I certainly understand a lot of the gripes that people have had, but the amount of tribal knowledge for obscure platform behaviors encoded in CMake is…vast. I am certainly in the "things need to improve" camp, but I don't think burning all the bridges that have been built is the way to go either.
tomn 4y ago
While what you said is true, for outsiders it misses the 'why' (which I'm sure you are aware of!). The idea with autotools is that the generated configure script (and other assorted files) is supposed to be forwards and backwards compatible with different systems. It's not perfect, but the behaviour is mostly locked down at the time it is built, based on the particular set of macros it is generated with. There are definitely aspects of this which don't work (it's nearly impossible to test, getting specific versions of autotools is presumably a PITA, and the make-in-bash-in-m4 language is deeply cursed), but the overall design does make some things better. For example, if your project needs a specific version of cmake, your users will have to figure out how to install it, but if your project requires a specific version of autotools, only your developers need to install it. (FWIW autotools is on my 'never again' list of technologies; it's incredibly cursed)
- verall 4y ago
  As long as your policies are set correctly (not that this is particularly easy), your project will only need a version of CMake or newer, not a specific version.
  - tomn 4y ago
    Yeah, they are quite good at compatibility. In practice there may often be an upper version limit if you happen to use any features which eventually get deprecated or removed.

rleigh 4y ago

The reason for the recent stability is that the Autotools have been essentially unmaintained for the past 15 years. When there were steady releases back in the early 2000s, we experienced regular incompatibilities and breakage. Today, there are occasional releases again, but the tools have painted themselves into a corner--it's almost impossible to make any change of note without breaking things.