3 ms·

There’s no point telling people not to do something if you don’t give them an alternative that does do all those things. (And no, “just use autotools” is not a

by pja 10y ago

There’s no point telling people not to do something if you don’t give them an alternative that does do all those things. (And no, “just use autotools” is not a viable answer.)

rwmj 10y ago
Autotools does do all of those things. I'm not a particular fan of it either, but when I'm packaging software for a Linux distro then I'd rather see autotools or cmake being used instead of some crappy custom build system that will require patching to make it work. There is room for someone to come up with a good build system. It had better do everything autotools and cmake do, and be well documented and widely used, so there's a rather large barrier to entry.
- _RPM 10y ago
  Auto tools is great. To compile all you do is ./configure make make install It couldn't be simpler. Even though I am part of the GitHub generation, I don't see why so many of my peers hate it. I actually like it.
  - wyldfire 10y ago
    This is kinda hilarious because, yes, "Autotools is great" [as a consumer]. But autotools and m4 is kinda awful to write IMO.
    - arglwarg 10y ago
      ... and autotools is actively hate-inducing if you have to debug it.
  - pja 10y ago
    autotools is pretty great for the end-user who wants to compile your code or the distributor who wants to package it up for Debian or whatever. It’s a crawling horror for the programmer that wants to use autotools as the build solution for their code however, which is the topic under discussion.
  - flohofwoe 10y ago
    This only works in the Unix world, on Mac only for command line tools (but only after installing autoconf and make), and not at all on Windows unless you install a complete Unix environment (cygwin or mingw).
    - slrz 10y ago
      Why would it only work with command line programs on the Mac? That's definitely not true, unless something changed very recently. Also, you don't need autotools itself to build a autotoolized program. The generated configure script is portable sh.
    - _RPM 10y ago
      Not really. the end user doesn't need autotools installed actually. To build the configure script from the "configure.in" file, you need autotools. Go ahead and try!
  - GFK_of_xmaspast 10y ago
    That's the ideal situation, yes, but god help you when something goes wrong.
    - _RPM 10y ago
      It's not that hard. I recently had to debug a memcached configure.in script. But, I consider myself a C programmer, so that fact might be source of bias.
- _ph_ 10y ago
  Whenever "configure" is looking for a fortran compiler in a clearly non-fortran program, one has to wonder why no one fixes the configure scripts. From all I learned it is, because the underlying scripts are close to unmaintainable. So from that perspective, a better build tooling should be a high priority.
  - IshKebab 10y ago
    No one fixes the configure scripts because they're thousands of lines of code in about three different archaic languages that nobody knows or cares about.
    - davexunit 10y ago
      Fix configure.ac, not configure which is effectively a binary.
aoloe 10y ago
Ehm ehm... every second reply around here is shouting "cmake"...
- pja 10y ago
  CMake is icky. I’ve never been comfortable with it. I’ll take hand written makefiles over CMake, unless I have to have Windows as a build target.
shoover 10y ago
I'm surprised no one says, "Just use waf." It does all those things. It's fast. It's cross-platform. The language is Python. It's a bit steep to learn and maybe doesn't have the most mature built-in recipes for certain complex builds like mobile or desktop frameworks, but it seems like those things would be addressed quickly if more people were using it. The maintainer is a class act, consistently putting out new features and bug fixes and working with pull requests.
- flohofwoe 10y ago
  WAF is not so much a build system, but a bunch of python scripts to create your own build system, it's in the same zoo as cmake, scons or premake, but (in my opion) worse than any of those. I might have had a bad first impression though because of the project I had to use WAF in had terribly complex WAF scripts.
  - shoover 10y ago
    True, they do call it a build system toolkit. But I think worse than the others is on the wrong track and the sentiment is too heavily influenced by your negative first impression. swtoolkit made scons really nice to work with (but couldn't fix the speed issues). It's a shame it was abandoned. In the same way, a thin layer of functions as demonstrated in the waf "toolkit" examples could lean on the power of waf and provide a build system every bit as snazzy as big, polished systems like bazel and buck, but it would work cross-platform out of the box and be extensible with only Python. But I think waf is close enough to being high level that no one bothers to create and polish a build system layer (maybe internally in companies, but the open source uses I've seen use pretty standard waf scripts).
davexunit 10y ago
>And no, “just use autotools” is not a viable answer. After packaging hundreds of programs for a GNU/Linux distro and dealing with handwritten Makefiles and other so-called autotools replacements: Yes, it is. If you want someone to be able to build and install your software, just use the Autotools. Yup, they are ugly, but they're still the only set of tools that works acceptably.
- radarsat1 10y ago
  Not only that, but every time I'm up against a problem building software that uses something else, it's like, "oh great now I have to figure out what their secret badly-documented variable names are and how to configure their XML/JSON/YAML/whatever" It's a pleasure when autotools is used because in generally I know it's going to be nothing much more than > --with-stuff/--without-stuff and > --prefix=$HOME/.local and when it's not, at least I know I can just grep the shell script and figure it out pretty quickly without having to learn a whole new programming language.

by pja 10y ago

There’s no point telling people not to do something if you don’t give them an alternative that does do all those things. (And no, “just use autotools” is not a viable answer.)

rwmj 10y ago

Autotools does do all of those things. I'm not a particular fan of it either, but when I'm packaging software for a Linux distro then I'd rather see autotools or cmake being used instead of some crappy custom build system that will require patching to make it work. There is room for someone to come up with a good build system. It had better do everything autotools and cmake do, and be well documented and widely used, so there's a rather large barrier to entry.

_RPM 10y ago
Auto tools is great. To compile all you do is ./configure make make install It couldn't be simpler. Even though I am part of the GitHub generation, I don't see why so many of my peers hate it. I actually like it.
- wyldfire 10y ago
  This is kinda hilarious because, yes, "Autotools is great" [as a consumer]. But autotools and m4 is kinda awful to write IMO.
  - arglwarg 10y ago
    ... and autotools is actively hate-inducing if you have to debug it.
- pja 10y ago
  autotools is pretty great for the end-user who wants to compile your code or the distributor who wants to package it up for Debian or whatever. It’s a crawling horror for the programmer that wants to use autotools as the build solution for their code however, which is the topic under discussion.
- flohofwoe 10y ago
  This only works in the Unix world, on Mac only for command line tools (but only after installing autoconf and make), and not at all on Windows unless you install a complete Unix environment (cygwin or mingw).
  - slrz 10y ago
    Why would it only work with command line programs on the Mac? That's definitely not true, unless something changed very recently. Also, you don't need autotools itself to build a autotoolized program. The generated configure script is portable sh.
  - _RPM 10y ago
    Not really. the end user doesn't need autotools installed actually. To build the configure script from the "configure.in" file, you need autotools. Go ahead and try!
- GFK_of_xmaspast 10y ago
  That's the ideal situation, yes, but god help you when something goes wrong.
  - _RPM 10y ago
    It's not that hard. I recently had to debug a memcached configure.in script. But, I consider myself a C programmer, so that fact might be source of bias.
_ph_ 10y ago
Whenever "configure" is looking for a fortran compiler in a clearly non-fortran program, one has to wonder why no one fixes the configure scripts. From all I learned it is, because the underlying scripts are close to unmaintainable. So from that perspective, a better build tooling should be a high priority.
- IshKebab 10y ago
  No one fixes the configure scripts because they're thousands of lines of code in about three different archaic languages that nobody knows or cares about.
  - davexunit 10y ago
    Fix configure.ac, not configure which is effectively a binary.

aoloe 10y ago

Ehm ehm... every second reply around here is shouting "cmake"...

pja 10y ago
CMake is icky. I’ve never been comfortable with it. I’ll take hand written makefiles over CMake, unless I have to have Windows as a build target.

shoover 10y ago

I'm surprised no one says, "Just use waf." It does all those things. It's fast. It's cross-platform. The language is Python. It's a bit steep to learn and maybe doesn't have the most mature built-in recipes for certain complex builds like mobile or desktop frameworks, but it seems like those things would be addressed quickly if more people were using it. The maintainer is a class act, consistently putting out new features and bug fixes and working with pull requests.

flohofwoe 10y ago
WAF is not so much a build system, but a bunch of python scripts to create your own build system, it's in the same zoo as cmake, scons or premake, but (in my opion) worse than any of those. I might have had a bad first impression though because of the project I had to use WAF in had terribly complex WAF scripts.
- shoover 10y ago
  True, they do call it a build system toolkit. But I think worse than the others is on the wrong track and the sentiment is too heavily influenced by your negative first impression. swtoolkit made scons really nice to work with (but couldn't fix the speed issues). It's a shame it was abandoned. In the same way, a thin layer of functions as demonstrated in the waf "toolkit" examples could lean on the power of waf and provide a build system every bit as snazzy as big, polished systems like bazel and buck, but it would work cross-platform out of the box and be extensible with only Python. But I think waf is close enough to being high level that no one bothers to create and polish a build system layer (maybe internally in companies, but the open source uses I've seen use pretty standard waf scripts).

davexunit 10y ago

>And no, “just use autotools” is not a viable answer. After packaging hundreds of programs for a GNU/Linux distro and dealing with handwritten Makefiles and other so-called autotools replacements: Yes, it is. If you want someone to be able to build and install your software, just use the Autotools. Yup, they are ugly, but they're still the only set of tools that works acceptably.

radarsat1 10y ago
Not only that, but every time I'm up against a problem building software that uses something else, it's like, "oh great now I have to figure out what their secret badly-documented variable names are and how to configure their XML/JSON/YAML/whatever" It's a pleasure when autotools is used because in generally I know it's going to be nothing much more than > --with-stuff/--without-stuff and > --prefix=$HOME/.local and when it's not, at least I know I can just grep the shell script and figure it out pretty quickly without having to learn a whole new programming language.