> And much of the time, I find it faster and easier to fix a broken makefile than to fix broken autohell.

> And much of the time, I find it faster and easier to fix a broken makefile than to fix broken autohell. Exactly. 99% of the time, a broken makefile simply has an incorrect linker path or cflag. When it's not a path, the Makefile is structured in a way that makes sense and is easy to fix. If an autoconf project is broken, I just scrap it and don't even bother trying to build it. The other issue with autoconf is that it's not standardized. So many of the autoconf projects I've seen have shell scripts (to install it or download deps) mixed in that only add more confusion. Some of them have a configure script. Some have a configure.in, so you have to generate the configure yourself. 100% of the makefiles I've seen have a build, install and clean task. Sure, it's not required, but everybody does it. You can't say the same for autoconf.

Posted by charlesL on Jun 1, 2015, 4:14 PM

Tags

• reliability (Other)

Related issues

• This is my biggest problem with agents, they constantly defensively code for cases that have no chance of happening and in most cases a p...
• I wish there was something like LEAN for biology.
• The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
• I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
• I hate that I'm in deep enough to know what you mean.
• The biggest problem with “AI” is that big corps are shoving it down our throats.