3 ms·
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 t
by 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 agoWhy 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.