4 ms·

> In contrast, autotools, known for having a high learning curve, is really not that bad for people who already know unix. If you understand how to use a unix s

> In contrast, autotools, known for having a high learning curve, is really not that bad for people who already know unix. If you understand how to use a unix system, you can figure out autotools faster than you can cmake. And you can really know it, to the extent that you feel confident diving in and messing with its defaults, much sooner than you would with cmake. I've been using unix since 1992 and find the entire autotools suite to be almost incomprehensible. The low point was in 2014 when I was trying to compile a package that intentionally did not ship a configure file and made the user explicitly call autoconf. This would have been ok except that in the 3 or so years between when the code was released and I was trying to build it, autotools made some backward-incompatible changes and autoconf/automake errored out, with no indication of how to fix those. Eventually I just gave up and used a different package. Conversely, when I started using cmake (motivated by clion using it as a build system) I was able to get it up and running basically immediately, and 12 months later I appear to have become the cmake guru for my company.

mcguire 11y ago
"The low point was in 2014 when I was trying to compile a package that intentionally did not ship a configure file and made the user explicitly call autoconf." At the risk of having to admit I've had my share of bad experiences with autotools, don't ever do that. That is a big sign with flashing lights and sirens, saying that you should put that package down and leave it alone. Because... "This would have been ok except that in the 3 or so years between when the code was released and I was trying to build it, autotools made some backward-incompatible changes and autoconf/automake errored out, with no indication of how to fix those." The version of autotools someone was using when they wrote the scripts is very closely tied to the scripts. It's not at all a good idea to use a different version of the autotools.
- cdcarter 11y ago
  > At the risk of having to admit I've had my share of bad experiences with autotools, don't ever do that. That is a big sign with flashing lights and sirens, saying that you should put that package down and leave it alone. Because... And indeed, the exact issue the OP is complaining about is how the zipfile automatically created by GitHub has NOT had autotools run on it yet, and the maintainer cannot even manually overwrite that file!

mcguire 11y ago

"The low point was in 2014 when I was trying to compile a package that intentionally did not ship a configure file and made the user explicitly call autoconf." At the risk of having to admit I've had my share of bad experiences with autotools, don't ever do that. That is a big sign with flashing lights and sirens, saying that you should put that package down and leave it alone. Because... "This would have been ok except that in the 3 or so years between when the code was released and I was trying to build it, autotools made some backward-incompatible changes and autoconf/automake errored out, with no indication of how to fix those." The version of autotools someone was using when they wrote the scripts is very closely tied to the scripts. It's not at all a good idea to use a different version of the autotools.

cdcarter 11y ago
> At the risk of having to admit I've had my share of bad experiences with autotools, don't ever do that. That is a big sign with flashing lights and sirens, saying that you should put that package down and leave it alone. Because... And indeed, the exact issue the OP is complaining about is how the zipfile automatically created by GitHub has NOT had autotools run on it yet, and the maintainer cannot even manually overwrite that file!