4 ms·

I think autotool's biggest limitation is its UX: it's very difficult to learn what are the good practices, what's deprecated, what new resources are available t

by haolez 6y ago

I think autotool's biggest limitation is its UX: it's very difficult to learn what are the good practices, what's deprecated, what new resources are available to make your build scripts more robust. Discoverability is poor. Every autotools project that I come across is a mess of copy/paste from another autotools project, with unneeded (and sometimes wrong) checks and complexity.

nightowl_games 6y ago
Sounds just like cmake
- jnxx 6y ago
  In my experience, it is much better than cmake: Apart from having good and comprehensive introductory documentation, it has a nicely ordered reference and also, it is stable, while cmake is changing, sometimes in backward-incompatible ways, and you find a lot of information which is disconnected and fragmentary and one does not know to which versions it applies. The latter will also, by all experience I have, make it much much harder to maintain and fix cmake projects in the long run. Think in a "modern"C++ code base which is 15 years old and in which every developer tried to include its favorite language constructs.
Pinus 6y ago
Last time I looked at autoconf et al. from a developer's view -- which is, admittedly, probably 20 years ago -- the documentation was quite good. The discoverability of, for example, the C standard library is also quite poor if you do not read the manual.
- haolez 6y ago
  My take on discoverability is exactly being able to figure things out without the need for extensive documentation. The documentation should exist, of course, but you shouldn't need it for every corner.
  - jnxx 6y ago
    This is exactly my biggest problem with some other tools: That they try to automate everything with lots of "magic". And this does not lead to clearly understandable, well-defined systems which are maintainable in the long run. If one is debugging hard problems, for example in multi-threaded code with deadlocks, what happens is that one needs to get a very clear understanding of what a certain piece of code does. The same is the case for debugging build systems. In the end, the build system needs to deliver an efficient, clearly understandable, unambiguous definition of how the software is constructed from the different pieces. Some systems seem to try to absolutely minimize the amount of configuration code which is required for simple things, using "automatic configuration". If this is for clearly defined things like configuring a library to be static, this is fine. But when it becomes unclear and ambiguous what actually happens, or, worse, when you can't say what versions of dependencies are actually used, this is too much magic. And also when one needs twenty minutes or more to figure out how to switch on address sanitizer, or use a specific language standard. And this becomes worse when the configuration becomes more automagical with each iteration of the build software and the constructs and semantics start to depend on which version of the tool one is using. autotools has the advantage that these things are quite explicit, and the configuration interface is very stable, and this helps to understand and maintain a system.
jnxx 6y ago
I just learned it three days ago, based on the tutorials I linked, and I found it quite easy to learn. In particular, it has very good introductory as well as reference documentation.
- jnxx 6y ago
  Here is a reddit link which shows a minimal setup: https://old.reddit.com/r/programming/comments/a02n5/trying_qmake_and_cmake_as_an_autotools_user/c0f8ovu/ https://old.reddit.com/r/programming/comments/a02n5/trying_q... This is all one needs to start a project. I actually think it is a good idea to use it quite regularly for hobby projects as well, just like "git init ." .

by haolez 6y ago

nightowl_games 6y ago

Sounds just like cmake

jnxx 6y ago
In my experience, it is much better than cmake: Apart from having good and comprehensive introductory documentation, it has a nicely ordered reference and also, it is stable, while cmake is changing, sometimes in backward-incompatible ways, and you find a lot of information which is disconnected and fragmentary and one does not know to which versions it applies. The latter will also, by all experience I have, make it much much harder to maintain and fix cmake projects in the long run. Think in a "modern"C++ code base which is 15 years old and in which every developer tried to include its favorite language constructs.

Pinus 6y ago

Last time I looked at autoconf et al. from a developer's view -- which is, admittedly, probably 20 years ago -- the documentation was quite good. The discoverability of, for example, the C standard library is also quite poor if you do not read the manual.

haolez 6y ago
My take on discoverability is exactly being able to figure things out without the need for extensive documentation. The documentation should exist, of course, but you shouldn't need it for every corner.
- jnxx 6y ago
  This is exactly my biggest problem with some other tools: That they try to automate everything with lots of "magic". And this does not lead to clearly understandable, well-defined systems which are maintainable in the long run. If one is debugging hard problems, for example in multi-threaded code with deadlocks, what happens is that one needs to get a very clear understanding of what a certain piece of code does. The same is the case for debugging build systems. In the end, the build system needs to deliver an efficient, clearly understandable, unambiguous definition of how the software is constructed from the different pieces. Some systems seem to try to absolutely minimize the amount of configuration code which is required for simple things, using "automatic configuration". If this is for clearly defined things like configuring a library to be static, this is fine. But when it becomes unclear and ambiguous what actually happens, or, worse, when you can't say what versions of dependencies are actually used, this is too much magic. And also when one needs twenty minutes or more to figure out how to switch on address sanitizer, or use a specific language standard. And this becomes worse when the configuration becomes more automagical with each iteration of the build software and the constructs and semantics start to depend on which version of the tool one is using. autotools has the advantage that these things are quite explicit, and the configuration interface is very stable, and this helps to understand and maintain a system.

jnxx 6y ago

I just learned it three days ago, based on the tutorials I linked, and I found it quite easy to learn. In particular, it has very good introductory as well as reference documentation.

jnxx 6y ago
Here is a reddit link which shows a minimal setup: https://old.reddit.com/r/programming/comments/a02n5/trying_qmake_and_cmake_as_an_autotools_user/c0f8ovu/ https://old.reddit.com/r/programming/comments/a02n5/trying_q... This is all one needs to start a project. I actually think it is a good idea to use it quite regularly for hobby projects as well, just like "git init ." .