4 ms·
In the past, I've wrangled with autotools more than I'd care to admit. I spent very many hours indeed perfecting my automake files, configure scripts, libtool a
by metafunctor 10y ago
In the past, I've wrangled with autotools more than I'd care to admit. I spent very many hours indeed perfecting my automake files, configure scripts, libtool and gettext integrations, making sure you can pass in CPPFLAGS and LDFLAGS as one might expect, cross compiling, with all the .in and .in.in and .h.in files, with all the m4 macros, publishing some of my own autoconf macros, all the while figuring out how to make it all work on Linux, mingw, the various bsd derivatives, AIX, Solaris, HP-UX, OS X, Visual C compilers, and what have you.
From the developer's perspective, it is an absolute nightmare – and I consider myself a seasoned professional with the various unix-like systems and their shells. Even with this deliberate care, dedication, and time spent preparing the scripts beforehand, the build usually doesn't work properly out of the box on a new platform.
My mistake was in thinking that the value in autotools system is that you can build a system that will compile for anything. I imagined all you need to do is use (or create) feature tests to sniff out any differences between platforms, and your code will build and work anywhere.
The real value of autotools is for the user. The user can run "./configure && make && make check && make install".
Don't make the mistake I did, thinking that autotools will save you time. It absolutely will not.
- ufo 10y agoI really wish there were an alternative to the autotools that offered that configure make install interface without the nightmarish developer experiente. Perhaps by compromising on the portability, if that is the only way.
- contras1970 10y agohttps://github.com/roman-neuhauser/motoconf https://github.com/roman-neuhauser/motoconf aims for that space, sadly it's very incomplete and dormant.
- Sir_Cmpwn 10y agoI wrote a simple PoC of a simpler way to achieve something similar: https://github.com/SirCmpwn/scmake https://github.com/SirCmpwn/scmake It's definitely not something you should use, but I hope new things take a similar approach. It's small, give it a read. Here's a somewhat more complicated project that uses it: https://github.com/SirCmpwn/libccmd https://github.com/SirCmpwn/libccmd I think from a usability standpoint (both for devs and users) it's really great but the internals could use some work.
- js2 10y agoCMake, SCons, maybe. This question was closed as not constructive, but the discussion looks reasonable to me: http://stackoverflow.com/questions/600274/alternatives-to-autoconf-and-autotools http://stackoverflow.com/questions/600274/alternatives-to-au...
- ryandrake 10y agoCMake was a step in the right direction, but it, too, suffers from thousands of under-documented options and fiddly behavior. In a former life I was tasked with maintaining a CMakeLists.txt for a project with multiple dependent libraries, binary blobs, open source dependencies that needed to get pulled in, and the whole thing had to be built for Windows, Linux, Mac, iOS, Android, and a handful of other lesser-known mobile platforms. I wouldn't wish that on my worst enemy.
- cardiffspaceman 10y agoIt's not so bad. I have experience with two slightly different build systems based on CMake, which had to have customized toolchain definitions and build Cairo and WebKit. The Cairo build had a custom backend, which we integrated into Cairo's autotools. Cairo was driven using its autotools via CMake's "superproject" system.
- medenhill 10y agohttps://github.com/edenhill/mklove https://github.com/edenhill/mklove - mklove is end-user compatible with autoconf, without the nightmares.