3 ms·

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 discoverab

by 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.

by Pinus 6y ago

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.