3 ms·

The analysis on the whole seems to make sense What we need is a converter from Autotools to cmake, or some other system and then take Autotools to a farm upsta

The analysis on the whole seems to make sense What we need is a converter from Autotools to cmake, or some other system and then take Autotools to a farm upstate for retirement

kergonath 5y ago
Cmake is just another hair ball, with its arcane syntax and incomprehensible errors. Plus, as mentioned it’s way less friendly to final users who have to compile the code from a tarball without knowing the intricacies of the build system. There is pretty much no advantage in going from autotools to cmake. If there is a jump to make, it’s to something better like meson.
- charcircuit 5y ago
  >There is pretty much no advantage in going from autotools to cmake. - faster builds - progress indicator
  - kergonath 5y ago
    Yes, the project indicator is nice, good point. Personally I haven’t really noticed any big difference in building time, parallel make seems good enough for my uses.
rurban 5y ago
What we really need is a tool to convert from an arcane and underpowered silly build tool like cmake to proper autotools, like autoupdate. And then farm cmake to retirement. Or keep it to the poor windows folks. A maintain dozens of mixed autotools, cmake and some header-only/makefile-only projects. The cmake build recipes are constantly behind and fragile. The makefile-only projects are a dirty hack, and very limited. autotools is easily the best, with support for everything. And if it's not in autoconf, then it's in autoconf-archive. meson and ninja are cool, but overkill mostly. We had dozens of such build tools before, and they all died. I even have to teach GNU maintainers how to use autotools/automake properly, as they cannot deal with recursive subdirs, rather have their own configure.in in each subdir. Of course this doesn't scale well.
- raverbashing 5y ago
  "to proper autotools" ah yes, the usual "you're holding it wrong" defense No, another hack on top of the auto-* ecosystem won't make things better. CMake's problems are cmakes's problems, but it doesn't make autostuff better in any way But please tell me again why do I need a buildsystem that needs to check if I have Fortran or if I'm running AIX under MIPS again? Makefile only is crude but it can work fine if your target is the usual distros and your project is small (read: less trouble than autotools)
  - rurban 5y ago
    > But please tell me again why do I need a buildsystem that needs to check if I have Fortran or if I'm running AIX under MIPS again? If you need Fortran support you need to check for it. Ditto for AIX. Hardcoding assumptions is fragile.
    - trasz 5y ago
      Why would you need to check for it? The name of compiler is well known, the build will properly fail if it’s not there, and work otherwise. Autotools doesn’t serve any purpose here.

The analysis on the whole seems to make sense What we need is a converter from Autotools to cmake, or some other system and then take Autotools to a farm upstate for retirement

kergonath 5y ago

Cmake is just another hair ball, with its arcane syntax and incomprehensible errors. Plus, as mentioned it’s way less friendly to final users who have to compile the code from a tarball without knowing the intricacies of the build system. There is pretty much no advantage in going from autotools to cmake. If there is a jump to make, it’s to something better like meson.

charcircuit 5y ago
>There is pretty much no advantage in going from autotools to cmake. - faster builds - progress indicator
- kergonath 5y ago
  Yes, the project indicator is nice, good point. Personally I haven’t really noticed any big difference in building time, parallel make seems good enough for my uses.

rurban 5y ago

What we really need is a tool to convert from an arcane and underpowered silly build tool like cmake to proper autotools, like autoupdate. And then farm cmake to retirement. Or keep it to the poor windows folks. A maintain dozens of mixed autotools, cmake and some header-only/makefile-only projects. The cmake build recipes are constantly behind and fragile. The makefile-only projects are a dirty hack, and very limited. autotools is easily the best, with support for everything. And if it's not in autoconf, then it's in autoconf-archive. meson and ninja are cool, but overkill mostly. We had dozens of such build tools before, and they all died. I even have to teach GNU maintainers how to use autotools/automake properly, as they cannot deal with recursive subdirs, rather have their own configure.in in each subdir. Of course this doesn't scale well.

raverbashing 5y ago
"to proper autotools" ah yes, the usual "you're holding it wrong" defense No, another hack on top of the auto-* ecosystem won't make things better. CMake's problems are cmakes's problems, but it doesn't make autostuff better in any way But please tell me again why do I need a buildsystem that needs to check if I have Fortran or if I'm running AIX under MIPS again? Makefile only is crude but it can work fine if your target is the usual distros and your project is small (read: less trouble than autotools)
- rurban 5y ago
  > But please tell me again why do I need a buildsystem that needs to check if I have Fortran or if I'm running AIX under MIPS again? If you need Fortran support you need to check for it. Ditto for AIX. Hardcoding assumptions is fragile.
  - trasz 5y ago
    Why would you need to check for it? The name of compiler is well known, the build will properly fail if it’s not there, and work otherwise. Autotools doesn’t serve any purpose here.