3 ms·

Yeah, the autotools model of portability didn't stand the test of time, but there's no shame in that. It's in good company. Isn't CMake the usual tool these day

Yeah, the autotools model of portability didn't stand the test of time, but there's no shame in that. It's in good company. Isn't CMake the usual tool these days?

rectang 6y ago
Autotools, during its lifetime, has provide tremendous value across innumerable scenarios and systems. What does it matter if it didn't stand the "test of time" — especially if it shone a light for its successors to follow? The Autotools model of probing for system capabilities at build time isn't dead; it will never die, it will only be used in greater and lesser amounts and to complement other means of discovering system capabilities. CMake seems to me like a reimplementation of the Autotoools model of build-time probing. The true competitors are binary distribution after building on precursor systems with full specification and no probing, and cross-compilation with full specification and no probing.
- jfb 6y ago
  Saying that something is obsolete isn't a value judgement -- it's an observation of the differences between the state of the world when it was necessary and now. This describes autotools to a 't'. It's not that there are that many fewer build targets these days, but rather that there are many many many fewer installations of most of those build targets these days.
1996 6y ago
> Yeah, the autotools model of portability didn't stand the test of time, but there's no shame in that. xmkmf joined the chatroom
rurban 6y ago
Cmake is only useful in very limited scenarios. I do maintain lots of projects with both, and cmake is always the second citizen, for msvc users only. Serious users use autotools (with mingw), but the occasional windows noob cannot be helped. So he gets his limited cmake experience. Cmake usually only does a tenth of the autotools probes, edge cases will never be detected and worked around. Such as broken compiler versions, as with gcc or icc frequently. Cmake is a visual basic like hack, but Visual Basic at least had a proper design. Just lacked the library infrastructure. Everybody uses autotools, show me a cmake-based distro. All this autotools bashing is hilarious. Probing is costly yes, but you only do it once, and you rarely do it by yourself. Distro packagers do that for you.
- jcranmer 6y ago
  > Everybody uses autotools, show me a cmake-based distro. The LLVM project exclusively uses cmake.
- rleigh 6y ago
  This is a complete mischaracterisation of CMake usage. Today, it's better at portability than most Autotools builds I've used. In projects which maintain both systems side-by-side, I've had Autotools fail on Solaris, MinGW and Cygwin while with CMake it worked without trouble. And that's for projects which hadn't specifically tested and fixed defects for portability issues on these platforms. Empirically, CMake had better platform coverage. As for the probing of features, take an actual look at what CMake provides. Over an order of magnitude more feature tests. The problem with the Autoconf feature testing is that the vast majority of the tests are 15 years obsolete at this point. The CMake tests are mostly for contemporary platforms. That's where the value lies.

Yeah, the autotools model of portability didn't stand the test of time, but there's no shame in that. It's in good company. Isn't CMake the usual tool these days?

rectang 6y ago

Autotools, during its lifetime, has provide tremendous value across innumerable scenarios and systems. What does it matter if it didn't stand the "test of time" — especially if it shone a light for its successors to follow? The Autotools model of probing for system capabilities at build time isn't dead; it will never die, it will only be used in greater and lesser amounts and to complement other means of discovering system capabilities. CMake seems to me like a reimplementation of the Autotoools model of build-time probing. The true competitors are binary distribution after building on precursor systems with full specification and no probing, and cross-compilation with full specification and no probing.

jfb 6y ago
Saying that something is obsolete isn't a value judgement -- it's an observation of the differences between the state of the world when it was necessary and now. This describes autotools to a 't'. It's not that there are that many fewer build targets these days, but rather that there are many many many fewer installations of most of those build targets these days.

1996 6y ago

> Yeah, the autotools model of portability didn't stand the test of time, but there's no shame in that. xmkmf joined the chatroom

rurban 6y ago

Cmake is only useful in very limited scenarios. I do maintain lots of projects with both, and cmake is always the second citizen, for msvc users only. Serious users use autotools (with mingw), but the occasional windows noob cannot be helped. So he gets his limited cmake experience. Cmake usually only does a tenth of the autotools probes, edge cases will never be detected and worked around. Such as broken compiler versions, as with gcc or icc frequently. Cmake is a visual basic like hack, but Visual Basic at least had a proper design. Just lacked the library infrastructure. Everybody uses autotools, show me a cmake-based distro. All this autotools bashing is hilarious. Probing is costly yes, but you only do it once, and you rarely do it by yourself. Distro packagers do that for you.

jcranmer 6y ago
> Everybody uses autotools, show me a cmake-based distro. The LLVM project exclusively uses cmake.
rleigh 6y ago
This is a complete mischaracterisation of CMake usage. Today, it's better at portability than most Autotools builds I've used. In projects which maintain both systems side-by-side, I've had Autotools fail on Solaris, MinGW and Cygwin while with CMake it worked without trouble. And that's for projects which hadn't specifically tested and fixed defects for portability issues on these platforms. Empirically, CMake had better platform coverage. As for the probing of features, take an actual look at what CMake provides. Over an order of magnitude more feature tests. The problem with the Autoconf feature testing is that the vast majority of the tests are 15 years obsolete at this point. The CMake tests are mostly for contemporary platforms. That's where the value lies.